Înainte să începi
Notează Java sau Bedrock, versiunile clientului și serverului, adresa cu port și ora exactă. Păstrează consola și ultimele modificări. Înainte să schimbi lumi, moduri sau fișiere, pregătește o copie restaurabilă și ține separat starea originală.
Confirmă ediția și adresa
Java și Bedrock sunt tipuri diferite: Java folosește de obicei TCP, iar Bedrock UDP. Alt port nu le face compatibile. Utilizează adresa alocată în panel și verifică ținta DNS ori SRV Java. Administrarea accesibilă nu dovedește că testezi portul corect de joc; porturile standard nu promit aceeași alocare pe un nod partajat. Verifică ediția utilizată efectiv de comunitate.
Jocul Java utilizează în general un punct final TCP, în timp ce jocul pe server Bedrock utilizează UDP. Valorile implicite comune nu înlocuiesc niciodată alocarea panoului. Pe un nod partajat, copierea unui port implicit dintr-un tutorial poate intra în conflict cu o altă instanță. Un test TCP nu poate valida conectivitatea Bedrock UDP.
Testează doar conexiunea TCP Java din Windows
Test-NetConnection -ComputerName 192.0.2.10 -Port 25565Înlocuiește adresa și portul cu alocarea reală. TcpTestSucceeded=True confirmă doar conexiunea TCP, nu UDP Bedrock, autentificarea Minecraft sau performanța. La False, compară portul ascultat, pornirea și regulile portului respectiv.
Verifică finalizarea pornirii
Procesul poate rula cât lumea încă se încarcă. Găsește mesajul de disponibilitate și erorile Java, de configurare, pluginuri sau moduri. Dacă serverul repornește permanent, investighează întâi ciclul. Restarturile rapide adaugă încărcare și pot ascunde indicii. Păstrează mesajele și nu schimba simultan lumea, versiunea și toate extensiile fără identificarea unei cauze și fără o copie funcțională.
După ce adăugați un plugin sau un mod, verificați dependențele acestuia și compatibilitatea cu motorul. Paper, Fabric, Forge și NeoForge nu încarcă automat aceleași extensii. Utilizați o copie de testare și eliminați numai adaosul identificat; ștergerea unei lumi nu este o modalitate de a diagnostica o eroare de software.
Testează protocolul necesar
Verifică asocierea autorizată dintre IP public și portul jocului. TCP nu validează un port Bedrock UDP. Bedrock cu vizibilitate LAN poate deschide și porturi standard suplimentare chiar când ai configurat alt port; pe gazdă partajată trebuie respectată schema operatorului. Nu deschide singur porturi suplimentare ori alocate altor clienți. Proxy-ul intermediar trebuie să suporte efectiv ediția și protocolul ales.
Apoi comparați de la o altă conexiune autorizată. Când o singură rețea eșuează, înregistrați furnizorul și orele, în loc să schimbați imediat configurația globală. Ping ICMP blocat nu stabilește că jocul este inaccesibil; un răspuns ping nu dovedește nici că portul de joc este deschis.
Verifică DNS Java fără să modifici zona
dig +short A play.example.com
dig +short SRV _minecraft._tcp.play.example.comO înregistrare SRV Java poate indica altă destinație și alt port. Rezolvă și numele returnat, apoi compară-l cu alocarea. SRV nu este necesar dacă clientul folosește deja adresa și portul corecte. Acesta nu este un test UDP Bedrock.
Compară versiunile și dependențele
Verifică versiunea jocului, software-ul și loaderul. Un modpack poate necesita aceeași combinație la client și server. Dacă problema urmează unei schimbări, verifică dependența păstrând copia. O versiune mai veche ori altă lume poate fi incompatibilă cu datele. Nu șterge originalul sau toate modurile pentru un experiment; păstrează un punct separat de recuperare și jurnalul schimbărilor.
Bedrock LAN discovery poate deschide și porturile sale obișnuite pe lângă un port personalizat. Pe un nod partajat, utilizați configurația adaptată a panoului și solicitați o verificare a conflictului de alocare. Pentru un proxy Java sau un gateway de redare încrucișată, inspectați fiecare etapă a căii și nu numai adresa publică.
Măsoară când problema apare
Urmărește procesorul, memoria și consola în același interval. Un fir principal saturat poate bloca jocul cu medie mică pe gazdă. În Paper, spark ajută la profilarea problemei în timpul apariției. Verifică distanțele de vedere și simulare și suprascrierile din alte configurații. RAM suplimentar nu repară automat acest lucru; contează setările efective, nu doar ce ai scris într-un fișier.
Acolo unde este acceptat, profilați serverul în timpul problemei cu un instrument compatibil. Versiunile recente Paper includ spark. Un raport de la un server gol este mai puțin util decât unul capturat în timpul încetinirii. Limitați înregistrarea și protejați legăturile de diagnosticare care pot conține informații sensibile.
Construiește o diagnoză reproductibilă
Compară un al doilea acces și identifică jucătorii afectați. Păstrează ora, endpointul și mesajele, fără secrete sau date private. Timeout poate veni din rutare, filtre, protocol greșit sau server nepregătit. Indică un atac sau lipsă de resurse numai dacă datele rețelei și aplicației susțin concluzia. O deconectare izolată nu ajunge pentru acest diagnostic; oferă asistenței pași concreți.
Activitatea suspectată a DDoS necesită corelare cu măsurătorile de trafic sau cu evenimentele de atenuare. Numai un timeout este o dovadă insuficientă. Evitați repornirile repetate și scanările agresive: acestea adaugă încărcare și îngreunează diagnosticarea. Testați remedierea folosind o conexiune normală, apoi verificați dacă jucătorii obișnuiți pot reveni.
Ce să faci în situația ta
| Situație | Pasul următor |
|---|---|
| Ediție greșită | Alege Java sau Bedrock cu endpointul real. Schimbarea portului nu convertește ediția. |
| Problemă după moduri sau lume | Compară versiuni și dependențe, păstrând o copie separată a stării anterioare. |
| Eroare doar sub sarcină | Profilează firul principal și chunkurile în timpul problemei înainte de mărirea planului. |
Surse oficiale
Aceste surse explică protocoalele și setările menționate. Verifică documentația pentru versiunea pe care o folosești.