Portkontrollen säger öppen? Varför Minecraft-spelare fortfarande inte kan ansluta

Någon kör en portkontroll, ser ordet öppen och betraktar servern som löst. Vad det resultatet egentligen betyder är snävt: från kontrollens plats, i det ögonblicket, accepterades en TCP-anslutning till den adressen och den porten. Det säger ingenting om handskakningen i Minecraft-protokollet, kontobekräftelse eller om servern släppte in spelaren i en värld.

Det är fyra olika lager, och ett fel i något av dem ger spelaren samma mening: det fungerade inte.

En sond testar bara det den kan se

En TCP-anslutning slutförs när båda sidor avslutar trevägshandskakningen, som ligger under allt spelet vet. Sonden rapporterar att det fanns en lyssnare och att den svarade från sin nätverksplats. Den kan inte säga att lyssnaren är spelet, eftersom vilken process som helst kan binda en port och ta emot anslutningar.

Platsen betyder lika mycket som resultatet. En kontroll på det öppna internet testar en väg från ett nätverk. En kontroll som operatören kör inifrån samma nätverk testar en helt annan väg, och ett positivt resultat där säger nästan ingenting om vad en fjärrspelare upplever. Två olika kontroller hos två olika leverantörer kan till och med vara oense av skäl som inte har något med din server att göra.

Även tidpunkten spelar roll. Ett sondresultat beskriver ögonblicket då det kördes, och en hemanslutning med dynamisk adress eller ändrad vidarebefordringsregel kan flytta det verkliga svaret några minuter senare. Anteckna den offentliga adressen, porten, adressfamiljen och tiden tillsammans med domen, annars går observationen inte att upprepa. Upprepa kontrollen från ett verkligen annat nätverk i stället för från en telefon på samma anslutning.

Fyra lager mellan en socket och en spelare

Föreställ dig ordningen som en klient som ansluter faktiskt utför. Först löser den adressen, sedan öppnar den en TCP-anslutning till den publicerade porten, sedan talar den spelets eget protokoll för att förhandla och autentisera, och till sist avgör servern om den identiteten får komma in i världen. Varje lager har sin egen felsignatur, och bara det första är synligt för en portkontroll.

Standardporten för Java Edition är 25565, men operatören kan publicera en annan extern port och vidarebefordra den inåt, så numret en spelare skriver är inte nödvändigtvis numret servern ser. En kontroll riktad mot fel extern port rapporterar stängd medan servern är helt frisk, och det är det vanligaste falsklarmet i hela detta område.

Namn lägger till ett steg över porten. Om en spelare skriver ett värdnamn måste uppslagningen returnera den publicerade adressen, och på en maskin inne i nätverket kan den returnera en privat i stället. Det är inte ett brandväggsfel och ingen mängd portvidarebefordran kommer att ändra det.

Varför spelaren inifrån tar en annan väg

En spelare i samma LAN, eller i ett VPN som når det LAN:et, försöker nå den offentliga adressen inifrån. Begäran går till routerns externa adress och routern måste översätta den tillbaka inåt, vilket är arrangemanget som vanligen kallas hairpinning eller NAT-reflektion. Både översättningen utåt och returvägen måste stämma för att det ska fungera, och många konsumentroutrar implementerar det inte alls.

Därför kommer gästen utifrån in medan personen vid sidan av servern inte kan. Den externa vägen är verkligen i ordning; det är den interna omvägen som misslyckas, och den misslyckas på ett sätt som från spelarens skärm ser ut som ett serverproblem. Serverns egen logg avgör vilket som hände, eftersom en anslutning som aldrig översattes aldrig når den.

Det finns två ärliga rättelser och en dålig vana. De bra alternativen är att låta interna spelare använda den privata adressen eller ett split-DNS-namn som löses internt till den privata adressen, eller att aktivera reflektion på routern om funktionen finns och beter sig korrekt. Den dåliga vanan är att öppna fler portar eller stänga av värdens brandvägg, vilket inte kan påverka en översättning som routern aldrig utförde.

Netgates dokumentation om NAT-reflektion beskriver skillnaden mellan utsidan och insidan och split-DNS-alternativet mer detaljerat. Läs den som en beskrivning av mekanismen och inte som ett löfte att en viss VPN-leverantör eller router stöder varje loopback-variant.

Samla bevis från varje synvinkel

Skriv för varje test ned vem som körde det, varifrån, vid vilken tid, mot vilken adress och port, och vad servern loggade. En spelavvisning med tydlig anledning i serverkonsolen är ett annat fynd än en anslutning som aldrig kom fram, och de två pekar i motsatta riktningar.

Om tillåtna fjärrspelare kan ansluta och en lokal spelare inte kan, är den lokala vägen den återstående frågan och den förtjänar sin egen utredning: vilken adress klienten använde, vad routern gjorde med översättningen och om servern över huvud taget registrerade något anslutningsförsök. Lämna dessa tre fakta till den som äger nätverket i stället för att öppna portar på måfå.