Server Sons of the Forest není vidět nebo se nejde připojit

Když dedikovaný server Sons of the Forest není vidět nebo nepustí hráče dovnitř, příčinou je téměř vždy jedna z pěti věcí a podle příznaku poznáš, která z nich. Chybí v seznamu, ale jde se připojit přes adresu: query port 27016 nebo LanOnly. V seznamu je, ale každé připojení vyprší: herní port 8766, nebo IpAddress navázaná na špatné rozhraní. Připojí se a pak navždy visí na načítací obrazovce: port BlobSync 9700. Včera to fungovalo, dnes server odmítá všechny: herní patch a server, který nebyl aktualizován. Odmítá jen jednoho člověka: jeho heslo, verze jeho klienta nebo jeho síť. Všechny tři porty jsou UDP a pravidlo, které otevře místo nich TCP, je nejčastější způsob, jak udělat všechno správně a přesto neuspět.

Tento návod prochází jednotlivé příčiny popořadě, včetně kontrol, které je od sebe odliší. Instalace, všechny klíče v dedicatedserver.cfg a seznam vlastníků jsou popsané v návodu na dedikovaný server Sons of the Forest; sloty uložených her a přesun světů najdeš v článku nastavení a savy Sons of the Forest. Tady jde jen o jedno: dostat hráče z menu do světa.

Přiřaď příznak k příčině#

Začni tím, že si přesně ujasníš, co hráči vidí. „Nefunguje to“ zahrnuje půl tuctu nesouvisejících závad a oprava jedné z nich na ostatní nijak nepomůže.

Dva rychlé testy zúží problém rychleji než cokoli jiného. Zaprvé, může se někdo mimo tvoji síť připojit přes adresu? Pokud ano, server funguje a problém je v zobrazení v seznamu, v jednom klientovi nebo ve tvé vlastní LAN. Zadruhé, hlásí log serveru při startu úspěšný síťový test? Pokud hlásí zavřený port, ber to vážněji než webovou stránku routeru.

Tři porty a co který rozbije#

Sons of the Forest používá tři UDP porty, všechny se nastavují v dedicatedserver.cfg:

{  "IpAddress": "0.0.0.0",  "GamePort": 8766,  "QueryPort": 27016,  "BlobSyncPort": 9700}

Každý z nich selhává po svém a poznatelně, což se hodí, protože zavřený port můžeš většinou pojmenovat už podle příznaku.

• `QueryPort` (`27016`) používá master server Steamu a prohlížeč serverů ve hře, aby server viděly, přečetly jeho název a počet hráčů a změřily ping. Když ho zablokuješ, server dál běží a dál přijímá přímá připojení, ale v seznamu se nikdy neobjeví. Pokud se v seznamu server zobrazuje bez pingu nebo se zastaralým počtem hráčů, query provoz prochází jen občas nebo vůbec.
• `GamePort` (`8766`) nese samotnou herní relaci. Když ho zablokuješ, server se v seznamu může objevit - query port stále odpovídá - ale kliknutí na připojení skončí vypršením časového limitu.
• `BlobSyncPort` (`9700`) přenáší stav světa připojujícímu se hráči. Když ho zablokuješ, spojení se naváže, objeví se načítací obrazovka a nikdy se nedokončí. Tenhle port lidé přehlížejí, protože většina her na Steamu má jen první dva a kontrolní seznam zkopírovaný z jiné hry ho neobsahuje.

Všechny tři musí být UDP. Stránky pro přesměrování portů na domácích routerech často nabízejí jako výchozí TCP nebo „TCP/UDP“; zkontroluj, co sis vybral. Přesměrování 8766 pro TCP s touto hrou nedělá absolutně nic. Pokud ti ten rozdíl není jasný, v článku TCP vs UDP pro herní servery je vysvětleno, proč hry používají UDP a proč se kvůli tomu hůř testují.

Každé z těch tří čísel můžeš změnit. Obvyklý důvod je druhý server na stejném stroji, a pak se musí všechny tři porty u obou serverů lišit - dva servery se společným portem BlobSync způsobí přesně příznak zaseknutého načítání u toho, který se spustil později. Když v konfiguraci změníš port, změň zároveň přesměrování, pravidlo firewallu i všechno, co jsi hráčům řekl, aby zadávali. Port změněný na jednom místě a ne na ostatních stojí za velkou část hlášení typu „po úklidu to přestalo fungovat“. Obecný přehled herních, query a přenosových portů je v článku porty herních serverů vysvětlené a query porty a A2S popisuje, na co query port vlastně odpovídá.

Při startu server sám spustí test dostupnosti na všech třech portech a výsledek zapíše do konzole. Neúspěšný test ti řekne, který port považuje za zavřený, nebo že port je už používaný. „Už používaný“ obvykle znamená, že předchozí kopie serveru nikdy neskončila - zhroucený proces, který dál drží port - nebo že na tom čísle běží jiný program na stroji. Najdi starý proces a ukonči ho, než začneš měnit cokoli dalšího.

IpAddress: co bind nastavení opravdu dělá#

IpAddress je lokální adresa, na které server naslouchá. Není to adresa, kterou hráči zadávají, a není to tvoje veřejná IP.

0.0.0.0 znamená všechna rozhraní na stroji a na domácím PC, na VPS i v kontejneru je to přesně to, co chceš. Chyba, která se objevuje pořád dokola, je vepsat sem veřejnou adresu, protože se zdá, že server by svou adresu měl znát. Na stroji za routerem veřejná adresa nepatří žádnému rozhraní na tom stroji - patří routeru - takže se server snaží naslouchat na adrese, kterou nemá. Podle buildu to buď selže při startu, nebo vznikne server, který běží a nikdo se k němu nedostane.

Existují dva legitimní důvody nastavit něco jiného než 0.0.0.0:

• Stroj s několika síťovými rozhraními, například server s veřejnou a soukromou sítí, kde chceš hru na jedné a ne na druhé. Použij adresu toho rozhraní přesně tak, jak ji ukazuje operační systém.
• Stroj s několika veřejnými adresami, kde má každý herní server vlastnit jednu. I tady musí být adresa taková, kterou stroj skutečně má.

Ve Windows vypíše adresy stroje ipconfig, v Linuxu ip -4 addr. Pokud hodnota v IpAddress ve výpisu není, je špatně. Související past je domácí PC, jehož LAN adresa se po restartu změní, protože ji router přiděluje přes DHCP. Pokud ses navázal na 192.168.1.40 a stroj má teď 192.168.1.52, server naslouchá na ničem užitečném a router přeposílá na prázdnou adresu. V konfiguraci použij 0.0.0.0 a v routeru dej PC DHCP rezervaci, aby přesměrování vždy skončilo na stejném stroji.

Server také potřebuje veřejnou IPv4 adresu, aby se mohl zaregistrovat u Steamu. Připojení, které má jen IPv6 nebo jehož IPv4 je sdílená za carrier-grade NAT, může server spustit, aniž by ho mohlo zveřejnit nebo přijímat připojení. Log pak napíše, že od Steamu nezískal veřejnou adresu, nebo síťový test selže na všech portech najednou. Proč Steam hry stále počítají s IPv4, vysvětluje článek IPv6 a herní servery.

LanOnly, hairpin NAT a testování ze správného místa#

LanOnly nastavené na true drží server úplně mimo veřejný internet. Neregistruje se ve veřejném seznamu Steamu a hráči mimo tvoji síť se nepřipojí. Je to správné nastavení pro LAN párty a špatné pro všechno ostatní, a protože server nastartuje čistě tak i tak, vyplatí se ho zkontrolovat dřív, než se pustíš do hledání v nabídkách routeru.

Druhá past doma je testování zevnitř vlastní sítě. Většina spotřebitelských routerů nepodporuje hairpin NAT (také NAT loopback): PC v tvé LAN, které se připojuje na tvoji vlastní veřejnou adresu, se dovnitř nevrátí. Výsledkem je server, ke kterému se kamarádi z druhého konce města připojí bez problémů, ale ten, kdo ho hostuje, se na něj přes veřejnou IP nedostane. To není chyba serveru. Hostitel by se měl připojovat na LAN adresu serverového PC a všichni ostatní na veřejnou.

Stejný efekt rozbíjí i vlastní autotest serveru. Zkouší svou veřejnou adresu zevnitř sítě a bez podpory hairpin selže na serveru, který je zvenku naprosto dostupný. To je jediný dobrý důvod nastavit SkipNetworkAccessibilityTest na true: ověřil jsi s hráčem mimo svou síť, že připojení funguje, a test přesto tvrdí opak. Nastavit to jen proto, aby test mlčel, aniž bys mu rozuměl, jen skryje chybovou hlášku, zatímco hráči dál neuspějí.

Testuj tedy zvenku. Počítač kamaráda, telefon připojený přes mobilní data s hrou na notebooku nebo server jinde, který se umí dotázat Steamu - cokoli z toho ti řekne pravdu. Stroj, na kterém server běží, a cokoli v jeho LAN to nedokáže.

Hosting doma: přesměrování, firewally a CGNAT#

Pokud server běží na PC doma, mezi hráči a hrou stojí tři vrstvy a všechny potřebují stejné tři UDP porty.

1. Router. Přesměruj UDP 8766, 27016 a 9700 na LAN adresu serverového PC. Některé routery chtějí rozsah na jedno pravidlo; tři pravidla po jednom portu jsou v pořádku.
2. Firewall operačního systému. Ve Windows se při prvním naslouchání SonsOfTheForestDS.exe Windows Defender Firewall zeptá, jestli to povolit. Zavři ten dialog, nebo zaškrtni jen „soukromé sítě“, zatímco je tvoje síť označená jako veřejná, a příchozí provoz se zahodí bez dalšího slova.
3. Samotné připojení. Pokud tvůj poskytovatel používá carrier-grade NAT, žádné přesměrování nikdy nezafunguje, protože tvůj router veřejnou adresu nedrží.

Ve Windows je explicitní příchozí pravidlo spolehlivější než spoléhání na dialog. Z příkazového řádku spuštěného jako správce:

$ netsh advfirewall firewall add rule name="Sons of the Forest server" dir=in action=allow protocol=UDP localport=8766,27016,9700

Na linuxovém hostiteli, kde server běží pod Wine nebo Protonem a firewallem je ufw:

$ sudo ufw allow 8766/udp$ sudo ufw allow 27016/udp$ sudo ufw allow 9700/udp

Pokud server běží v Dockeru, každý port musí být publikovaný i s protokolem, například -p 9700:9700/udp. Docker publikuje ve výchozím stavu TCP a kontejner spuštěný s -p 9700:9700 má stejný problém chybějícího UDP jako přesměrování v routeru nastavené na TCP. Širší souvislosti pokrývají články firewallová pravidla, na kterých záleží a návod na ufw.

Abys poznal CGNAT, porovnej WAN adresu ze stavové stránky routeru s adresou, kterou ukáže stránka typu „what is my IP“. Pokud se liší, nebo WAN adresa routeru leží v 100.64.0.0/10, je tvoje připojení sdílené a příchozí přesměrování nemůže fungovat. Řešením je požádat poskytovatele o veřejnou IPv4 adresu, kterou někteří dají na požádání a někteří si za ni účtují, nebo provozovat server někde, kde ji mají. Možnosti rozebírá článek NAT a CGNAT pro herní hostitele a port forwarding vs hostované servery je upřímné srovnání boje s tím doma a pronájmu.

Na hostovaném serveru většina tohohle odpadá. Na RE:NODE jsou tarify pro Sons of the Forest dodávané se třemi přidělenými porty, které jsou už otevřené do internetu; před nimi není žádný router ani firewall Windows. Co zkontrolovat musíš, je, že tři čísla v dedicatedserver.cfg odpovídají přidělením zobrazeným na záložce Network, protože konfigurace zkopírovaná z domácího serveru si ponese domácí čísla portů.

Kontrola zvenku: uvádí ho vůbec Steam?#

Prohlížeč serverů ve hře se obnovuje pomalu a agresivně filtruje, takže „není v seznamu“ ve hře ne vždy znamená „není registrovaný“. Na tuto otázku přímo odpoví veřejné Web API Steamu. Vlož veřejnou IPv4 adresu serveru do této URL v libovolném prohlížeči:

https://api.steampowered.com/ISteamApps/GetServersAtAddress/v1/?addr=203.0.113.25

Vrátí všechny herní servery Steamu registrované z té adresy, spolu s porty, které Steam zná. Prázdný seznam znamená, že se server u Steamu neregistroval: podívej se na LanOnly, na problém s veřejnou IPv4 a na log serveru. Výsledek s tvým serverem znamená, že ho Steam má, a hráč, který ho ve hře stále nevidí, má nastavený filtr v prohlížeči, starou keš seznamu, nebo je query port zablokovaný mezi Steamem a serverem, takže ho prohlížeč nemůže pingnout.

Druhým názorem je vlastní prohlížeč serverů v klientu Steam. Ve Steamu otevři Zobrazit, pak Herní servery, přejdi na Oblíbené a přidej server podle adresy a query portu. Pokud tam odpoví s názvem a pingem, query provoz se k němu dostává. To se hodí k oddělení prohlížeče ve hře od sítě: pokud prohlížeč Steamu server vidí a hra ne, problém je na straně hry, obvykle ve filtru nebo v rozdílu verzí.

Nesoulad verzí po patchi#

Klient a server musí běžet na stejném buildu. Steam aktualizuje hráčům hru automaticky, obvykle ten den, kdy patch vyjde. Dedikovaný server je samostatná aplikace (2465200), která se aktualizuje, jen když proti ní někdo spustí SteamCMD. Den po patchi je tedy server na včerejším buildu a všichni, kdo se aktualizovali, jsou odmítáni - často hláškou, která o verzích nic neříká, nebo spojením, které prostě skončí.

Oprava je aktualizovat server a pak ho restartovat:

$ steamcmd +force_install_dir C:\sotf-server +login anonymous \    +app_update 2465200 validate +quit

Udělej to dřív, než se kdokoli pokusí připojit, a předtím si zkopíruj save, protože den patche je také nejpravděpodobnějším dnem pro změnu formátu savu. Článek SteamCMD vysvětlené popisuje validate a instalace a chyby SteamCMD a jejich opravy říká, co dělat, když selže samotná aktualizace.

Stává se i opačný nesoulad. Hráč, který si ve vlastnostech hry ve Steamu zapnul betu, je na jiném buildu než server běžící na veřejné větvi. Pokud se nemůže připojit právě jeden člověk, zatímco všichni ostatní ano, nech ho zkontrolovat záložku Betas ve Steamu a ověřit soubory hry. Opačný případ - server zaseknutý na starém buildu, zatímco hráči jdou dál - je způsob, jak server se skriptem se starým argumentem -beta tiše přestane přijímat kohokoli. Jak k tomu dochází, vysvětluje článek app ID SteamCMD a beta větve.

Návyk, který stojí za to si vytvořit: když se oznámí patch, aktualizuj a restartuj server ještě týž den a dej o tom skupině vědět. Kontrolní seznam pro den aktualizace herního serveru obsahuje kroky ve správném pořadí a automatizace aktualizací herních serverů popisuje, jak to předat někomu jinému - konkrétně naplánované úloze.

Hesla, která nefungují#

Password je v JSON obyčejný řetězec, nejvýše 40 znaků. Prázdný znamená žádné heslo. Selhat mohou tři věci:

• Velikost písmen a mezery. Shoda je přesná. Mezera na konci vložená z chatové zprávy je součástí hesla.
• Escapování v JSON. Heslo obsahující dvojitou uvozovku nebo zpětné lomítko se musí zapsat jako \" nebo \\, jinak se soubor přestane parsovat. Jednodušší je zvolit heslo bez nich.
• Přepsání z příkazové řádky. Každý konfigurační klíč lze nastavit na příkazové řádce s prefixem -dedicatedserver. a příkazová řádka vyhrává. Pokud panel nebo startovací skript předává -dedicatedserver.Password, změna souboru nic nezmění. Než usoudíš, že tě server ignoruje, zkontroluj startovací příkaz.

Heslo se uplatní při každém restartu, takže změna je otázkou zastavení a spuštění a svět se jí nedotkne. Pokud se jeden hráč nedostane dovnitř s heslem, které ostatním funguje, ať ho napíše ručně a nevkládá. Pokud se nedostane nikdo, přečti si ve startovacím logu řádek s konfigurací, než začneš podezírat síť.

Čtení logu serveru#

Výstup konzole je místo, kde se každý z těchto problémů ohlásí, a vyplatí se jednou přečíst ho od začátku do konce na funkčním serveru, abys věděl, jak vypadá normál. Při diagnostice spusť server s -verboseLogging; ty další podrobnosti dělají rozdíl mezi věděním a hádáním. Nastav LogFilesEnabled na true, pokud chceš výstup zapisovat i do souborů ve složce uživatelských dat, přičemž TimestampLogFilenames udrží každý start v samostatném souboru.

Na co se dívat, popořadě:

1. Načítání konfigurace. Chyba parsování znamená poškozený JSON - čárku navíc, chytré uvozovky, neescapovaný znak v heslu - a server tam skončí. Oprav soubor a spusť znovu.
2. Otevírání portů. Hláška „in use“ znamená, že číslo drží jiný proces. Ukonči ho, nebo přesuň tenhle server na volné porty.
3. Veřejná adresa od Steamu. Selhání tady znamená, že není k dispozici veřejná IPv4: připojení jen přes IPv6, CGNAT, nebo má Steam špatnou chvíli, a v tom případě stojí za jeden pokus restart o pár minut později.
4. Test síťové dostupnosti. Každý port je hlášen jako dosažitelný nebo ne. Jediný zavřený port pojmenuje tvůj problém. Všechny tři zavřené většinou znamenají, že přesměrování míří na špatný stroj, firewall zahazuje všechno, nebo test rozbíjí hairpin NAT.
5. Připojující se hráči. Při probíhajícím připojení log ukáže, že spojení dorazilo. Pokud se připojení na herní port objeví a nic dalšího nenásleduje, přenos BlobSync neprochází.

Na RE:NODE ukazuje konzole živý výstup serveru bez filtrování, takže síťový test i každé připojení se objeví přesně v okamžiku, kdy nastanou, a záložka Startup je místo, kde žijí všechna přepsání z příkazové řádky. Tam se podívej jako první, když se zdá, že hodnota v souboru je ignorována.

Ještě jednu věc log prozradí: opakované restarty. Server, který padá při načítání, třeba kvůli poškozenému savu, se restartuje a krátce vypadá jako „online“, než zase zmizí. Pro hráče to nejde odlišit od síťového problému. Pokud se uptime v konzoli pořád resetuje, problém je v serveru, ne v portech - začni článkem proč se váš herní server pořád restartuje.

FAQ#

Proč se můj server ukazuje kamarádům, ale mně ne?

Jsi ve stejné síti jako server a tvůj router neposílá provoz na vlastní veřejnou adresu zpátky dovnitř. Připoj se přes LAN adresu serverového PC. Všichni mimo tvoji síť používají veřejnou adresu jako obvykle.

Které porty musím pro Sons of the Forest přesměrovat?

UDP 8766 pro hru, UDP 27016 pro dotazy Steamu a UDP 9700 pro BlobSync, pokud jsi je v dedicatedserver.cfg nezměnil. Všechny tři musí být UDP. Chybějící třetí způsobuje nekonečnou načítací obrazovku.

Mám do IpAddress dát svou veřejnou IP?

Ne. IpAddress je lokální rozhraní, na kterém se naslouchá, a 0.0.0.0 znamená všechna. Konkrétní adresu nastav jen tehdy, když má stroj několik rozhraní a chceš server na jednom z nich, a pak použij adresu, kterou stroj sám má.

Hráče po aktualizaci hry vyhodilo zpět do menu. Co se stalo?

Jejich hra se aktualizovala a server ne. Zastav server, spusť přes SteamCMD app_update 2465200 a spusť ho znovu. Nejdřív zálohuj save, protože formáty se mění právě v den patchů.

Je bezpečné zapnout SkipNetworkAccessibilityTest?

Až poté, co se někdo mimo tvoji síť úspěšně připojil. Test falešně selhává za NATem bez podpory loopbacku a v tom případě je jeho přeskočení v pořádku. Pokud se nepřipojí nikdo, přeskočení nezmění nic kromě hlášky.

Můžu na jednom stroji provozovat dva servery?

Ano, pokud má každý vlastní tři porty a vlastní složku uživatelských dat přes -userdatapath. Dva servery sdílející jakýkoli jeden port - BlobSync se zapomíná nejsnáz - rozbijí připojení u toho, který se spustil později.