Vad bör du kontrollera när Tailscale inte kan nå din hemserver?

När Tailscale inte kan nå din hemserver är felet inte alltid inom Tailscale-nätverket självt. Servern kan vara offline, enhetsnamnet kanske inte löses, en åtkomstregel kan neka anslutningen, operativsystemets brandvägg kan blockera tjänsten eller applikationen kan bara lyssna på localhost.

Det snabbaste sättet att hitta orsaken är att felsöka i lager. Bekräfta först att båda Tailscale-noderna är online. Testa sedan serverns råa Tailscale-IP, separera grundläggande nodanslutning från applikationsåtkomst och gå endast vidare till subnet-routing eller DERP-felsökning när symptomen faktiskt pekar dit.

Börja med att identifiera vilket lager som misslyckas

Ett vanligt felsökningsmisstag är att behandla varje timeout som samma problem. En hemserver som verkar offline i tailnet är annorlunda än en server som svarar på Tailscale-ping men vägrar SSH- eller webbanslutning.

Tailscale tillhandahåller den privata nätverksvägen mellan enheter, men den slutgiltiga tjänsten beror fortfarande på serverns operativsystem, brandvägg, lyssnande port, applikationskonfiguration, Docker-nätverk och åtkomstpolicy. Att åtgärda fel lager kan skapa ytterligare problem utan att återställa anslutningen.

Innan du ändrar något, skriv ner det exakta symptomet. Kontrollera om servern verkar online, om dess Tailscale-IP svarar, om dess MagicDNS-namn löses och om den specifika applikationsporten accepterar en anslutning.

Bekräfta att båda Tailscale-noderna är online

Börja med de två enheterna som är involverade i anslutningen. Den fjärranslutna laptopen eller telefonen måste vara ansluten till tailnet, och hemservern måste också vara online under det förväntade kontot, taggen eller enhetsidentiteten.

På en Linux-server, kontrollera Tailscale-tjänsten och kör tailscale status. På stationära system, kontrollera att klienten är ansluten och inte pausad, utloggad eller väntar på autentisering. En server som misslyckades med att starta Tailscale efter en omstart kan inte fixas genom att ändra DNS eller applikationsportar.

Kontrollera också om servern visas under det förväntade enhetsnamnet och Tailscale-IP:n. Om noden är offline, åtgärda tjänsten, inloggningsstatus, systemstartbeteende eller klientversion innan du felsöker något ovanför nätverkslagret.

Använd den råa Tailscale-IP:n innan du testar ett värdnamn

Ett värdnamn lägger till DNS-upplösning i anslutningsvägen. Om du börjar med ett servernamn som hemserver eller nas-enhet, kan du inte omedelbart avgöra om felet beror på nätverk eller namnupplösning.

Hitta serverns Tailscale IPv4-adress, normalt i 100.x.x.x-intervallet, och testa den adressen direkt. När LAN-rutter, exit-noder eller överlappande subnät komplicerar vägen är det särskilt användbart att testa enhetens Tailscale-IP före dess privata LAN-adress.

Om den råa IP-adressen fungerar men värdnamnet inte gör det, är grundläggande nodanslutning troligen frisk. Gå vidare till MagicDNS och klientens DNS-inställningar istället för att installera om Tailscale eller ändra routern.

Om IP-adressen fungerar men namnet misslyckas, kontrollera MagicDNS

MagicDNS låter enheter använda läsbara maskinnamn istället för att komma ihåg Tailscale-IP-adresser. När det fungerar, en enhet som heter hemserver kan nås via det namnet från en annan enhet i samma tailnet.

Funktionen skapar automatiska enhetsnamn inom tailnet, men lyckad upplösning beror fortfarande på att enheten är ansluten och klienten accepterar tailnets DNS-konfiguration. Lokala DNS-filter, företags säkerhetsverktyg, anpassade resolver eller föråldrade cachade poster kan störa.

Jämför det korta värdnamnet, det fullständiga tailnet-namnet och den råa Tailscale-IP:n. Om endast namnen misslyckas, kontrollera om MagicDNS är aktiverat, om maskinen har bytt namn och om en annan DNS-produkt åsidosätter resolver-konfigurationen.

Separera Tailscale-anslutning från applikationsanslutning

En lyckad nod-till-nod-anslutning bevisar inte att varje tjänst på servern är nåbar. Du kan kunna pinga Tailscale-IP:n medan SSH, Jellyfin, en instrumentpanel, SMB eller ett Docker-webbgränssnitt fortfarande går ut på tid.

Det betyder vanligtvis att Tailscale-vägen finns men applikationslagret vägrar eller saknar anslutningen. Tjänsten kan vara stoppad, lyssna på en annan port, bunden till fel gränssnitt, blockerad av serverns brandvägg eller inte publicerad från sin container.

Testa den exakta destinationen du behöver, till exempel 100.x.x.x:22 för SSH eller http://100.x.x.x:8080 för en webbtjänst. Om noden svarar men porten inte gör det, sluta felsöka MagicDNS och DERP tills serverns tjänst är verifierad.

Kontrollera om tjänsten lyssnar på rätt gränssnitt

En applikation kan köras normalt på hemservern men ändå vara otillgänglig från alla andra enheter. Detta händer när tjänsten endast lyssnar på 127.0.0.1, som accepterar anslutningar från servern själv men inte via dess LAN- eller Tailscale-gränssnitt.

En tjänst som lyssnar på 0.0.0.0 accepterar IPv4-trafik på alla tillgängliga gränssnitt, medan en tjänst också kan vara bunden uttryckligen till serverns LAN-adress eller Tailscale-adress. Rätt val beror på om tjänsten ska vara nåbar från LAN, tailnet eller endast via en lokal omvänd proxy.

Ändra inte automatiskt varje tjänst till 0.0.0.0. Bekräfta först den avsedda åtkomstvägen och använd sedan brandväggsregler och applikationsautentisering för att begränsa vem som kan nå porten.

Serverns brandvägg kan blockera Tailscale-trafik

En tjänst kan fungera via hemserverns LAN-IP men misslyckas via dess Tailscale-IP eftersom operativsystemet behandlar Tailscale-gränssnittet som en separat nätverksväg. LAN-regler gäller inte alltid för trafik som anländer via tailscale0.

Linux-system kan använda UFW, firewalld, iptables eller nftables. Windows kan klassificera Tailscale-adaptern annorlunda än hemmets LAN. Större nätverksbrandväggar kan också förhindra direkta UDP-anslutningar och tvinga trafiken via relävägar. Den relevanta kontrollen är om din brandvägg tillåter den avsedda Tailscale-anslutningsvägen.

Inaktivera inte hela brandväggen som en permanent lösning. Tillåt endast den nödvändiga tjänsteporten från Tailscale-gränssnittet, valda Tailscale-adresser eller en lämplig tailnet-policy. Testa sedan applikationen direkt igen.

Kontrollera åtkomstpolicyer, behörigheter, taggar och enhetsidentitet

Om en Tailscale-enhet kan nå hemservern medan en annan inte kan, kan skillnaden vara avsiktlig policy snarare än ett nätverksfel. Åtkomst kan bero på användare, käll-enhet, destinationstagg, protokoll och port.

En server som är taggad för infrastrukturåtkomst kanske inte accepterar trafik från en personlig enhet om inte policyn tillåter den kombinationen. En regel som tillåter SSH tillåter inte nödvändigtvis webbpanelen på en annan port, och en delad enhet kan ha andra behörigheter än en enhet som ägs av samma användare.

Granska källidentitet, destinationsidentitet, servertaggar och begärd port tillsammans. En tillfällig bred regel kan hjälpa till att isolera ett policyproblem, men ersätt den med den snävaste korrekta regeln efter testning.

En direkt hemserver behöver ingen subnet-router

Om Tailscale är installerat direkt på hemservern, använd serverns egen Tailscale-IP eller MagicDNS-namn. En subnet-router krävs inte för att nå den maskinen.

Subnet-routrar löser ett annat problem: de ger åtkomst till enheter som inte själva kör Tailscale, såsom en skrivare, kamera, äldre NAS, smarta hem-enheter eller en annan maskin på hem-LAN.

Att lägga till subnet-routing till ett enkelt direkt nodproblem skapar fler ställen där anslutningen kan misslyckas. Bevisa först att Tailscale-klienten på hemservern är nåbar. Felsök endast annonserade LAN-rutter när det faktiska målet sitter bakom den servern.

Subnet-routing kräver en komplett routingkedja

När målet är en LAN-enhet utan Tailscale måste subnet-routern göra mer än att bara verka vara online. Den måste ta emot trafik från tailnet, vidarebefordra den in i hem-LAN och tillåta att svaret returneras.

En fungerande konfiguration kräver normalt IP-forwarding på routing-enheten, annonserade subnet-rutter, ruttgodkännande, matchande åtkomstkontroller och klient-sidans ruttacceptans där det krävs. Syftet är att annonsera ett privat subnet via en gateway så att tailnet-enheter kan nå maskiner som inte kör klienten.

Om rutten är synlig men trafiken misslyckas, kontrollera varje steg separat. Bekräfta att rätt subnet annonserades, verifiera att det godkändes, inspektera vidarebefordrande brandvägg och se till att LAN-enheten har en giltig returväg.

Överlappande privata subnet kan skicka trafik åt fel håll

Många hem-, kontors- och hotellnätverk återanvänder adresser som 192.168.1.0/24. Om ditt nuvarande Wi-Fi och ditt hem-subnet använder samma intervall, kan operativsystemet behandla destinationen som lokal istället för att skicka den via Tailscale.

Detta skapar ett förvirrande symptom: serverns direkta Tailscale-IP fungerar, men dess hem-LAN-IP gör det inte. Förfrågan kan gå till det aktuella nätverket istället för till den fjärranslutna subnet-routern.

Använd målets Tailscale-IP när det är möjligt. Om åtkomst till subnet är nödvändig, överväg att ändra ett LAN till ett mindre vanligt privat intervall eller att använda en routingdesign som hanterar överlappande nätverk medvetet.

En exit-nod kan ändra åtkomsten till det aktuella LAN:et

Om klientenheten använder en Tailscale exit-nod skiljer sig dess ruttval från en vanlig tailnet-anslutning. Åtkomst till närliggande LAN-enheter kan blockeras om inte lokal nätverksåtkomst uttryckligen tillåts.

Detta är viktigt vid felsökning från en laptop ansluten till hotell-, kontors- eller hemmets Wi-Fi samtidigt som du använder en exit-nod. Ett misslyckande att nå en privat LAN-adress kan bero på exit-nodens beteende snarare än hemmets server.

Testa utan exit-noden, eller aktivera endast LAN-åtkomst när du litar på det lokala nätverket. Aktivera inte bred lokal åtkomst automatiskt på okända offentliga Wi-Fi.

Docker lägger till en annan port- och gränssnittsspärr

En värdtjänst som SSH kan fungera via Tailscale medan en Docker-applikation på samma server misslyckas. Det pekar vanligtvis på container-nätverk snarare än nodanslutning.

Kontrollera om containern körs, om applikationen lyssnar inuti containern och om dess port är publicerad till värden. En Compose-mappning som 8080:80 exponerar containerport 80 via värdport 8080, medan en port som bara är bunden till 127.0.0.1 kan förbli otillgänglig via Tailscale-IP:n.

Kontrollera också omvända proxyvägar, värd-nätverk, Docker brandväggsregler och om applikationen själv tillåter anslutningar från icke-LAN-adresser. Testa värdporten direkt innan du felsöker högre nivåers domäner eller certifikat.

DERP förklarar vanligtvis långsamhet mer än fullständigt fel

Tailscale försöker skapa direkta anslutningar mellan enheter. När NAT-beteende eller brandväggsrestriktioner förhindrar detta kan det istället använda en reläväg.

DERP tillhandahåller en krypterad reläfallback när direktanslutning misslyckas. Reläet vidarebefordrar redan krypterad trafik och kan ansluta enheter över svåra kombinationer av IPv4, IPv6, NAT och brandväggar.

En DERP-väg fungerar ofta med högre latens eller lägre genomströmning, så det är en stark misstänkt när SSH känns segt eller filöverföringar är långsamma. Om anslutningen inte fungerar alls, kontrollera först nodstatus, åtkomstpolicy, lokal brandvägg, applikationsport och bindningsadress.

Använd Anslutningsdiagnostik innan du ändrar routern

Kommandon som tailscale ping hjälp att separera en nodväg från en applikationsväg. Ett lyckat resultat bevisar mer än en misslyckad webbläsarflik eftersom det testar anslutningen utan att förlita sig på applikationens port, proxy eller certifikat.

tailscale netcheck kan hjälpa till att visa UDP-tillgänglighet, NAT-beteende, IPv4- eller IPv6-anslutning och närliggande reläregioner. Dessa resultat är mest användbara när anslutningen bara fungerar via en relä eller ändras mellan nätverk.

Börja inte med att lägga till offentlig portvidarebefordran till hemroutern. Tailscale är designat för att fungera utan att exponera hemserverns applikationsportar direkt mot internet. Routerändringar bör göras som svar på ett bekräftat vägproblem, inte ersätta tidigare diagnostiska steg.

Starta om och uppdatera bara när du vet vilket lager som felar

Att starta om Tailscale kan återställa en felande daemon eller föråldrat klienttillstånd, men upprepade omstarter är ingen diagnos. Om samma fel återkommer efter varje omstart är det troligen startkonfiguration, brandväggspolicy, routing eller applikationsbindning som är problemet.

Bekräfta att hemservern startar Tailscale utan interaktiv inloggning på skrivbordet och förblir ansluten efter omstart. Jämför också klientversioner om en enhet beter sig annorlunda än resten av tailnet.

Efter en uppdatering eller omstart, upprepa samma tester i samma ordning: nodstatus, rå IP, värdnamn, Tailscale ping och applikationsport. En konsekvent testsekvens visar vilket lager som faktiskt ändrats.

Följ en felsökningsordning

Den snabbaste vägen är att gå från Tailscale-noden mot applikationen. Ändra inte DNS, subnet-rutter, brandväggsregler och Docker-nätverk samtidigt.

Bekräfta först att båda noderna är online. Testa sedan den råa Tailscale-IP:n, följt av MagicDNS-namnet. Testa nodvägen och sedan applikationsporten. Först efter dessa kontroller bör du undersöka serverns brandvägg, bindningsadress, åtkomstpolicy, Docker-mappning eller subnet-routing.

Denna ordning förhindrar att en enkel stoppad tjänst blir ett komplicerat routingprojekt. Varje test ska besvara en fråga innan du går vidare till nästa lager.

Slutsats

När Tailscale inte kan nå din hemserver, börja med den enklaste skillnaden: kan de två Tailscale-noderna kommunicera, och kan applikationen ta emot trafik? Bekräfta att båda noderna är online, testa den råa Tailscale-IP:n och testa sedan MagicDNS-namnet och den exakta tjänsteporten.

Om nodvägen fungerar men applikationen inte gör det, fokusera på serverns brandvägg, lyssnande gränssnitt, applikationsinställningar, Docker-portmappning och åtkomstpolicy. Om målet inte kör Tailscale, gå vidare till subnet-routerkonfiguration, ruttgodkännande, IP-vidarebefordran och kontroll av överlappande subnet.

DERP-relävägar förklarar vanligtvis långsammare prestanda snarare än total fel. Ett konsekvent lager-för-lager-test är mer effektivt än att installera om Tailscale, inaktivera brandväggen eller lägga till offentlig portvidarebefordran utan att veta var anslutningen bryts.

Vanliga frågor

Varför kan jag pinga min Tailscale-server men inte öppna dess webbgränssnitt?

Nod-till-nod-anslutningen fungerar, men webbservicen kan vara stoppad, lyssna på en annan port, bunden endast till localhost, blockerad av serverns brandvägg eller inte publicerad från dess Docker-container.

Varför fungerar Tailscale-IP:n men inte servernamnet?

Detta pekar på ett problem med MagicDNS eller annan DNS-konfiguration. Kontrollera om MagicDNS är aktiverat, om maskinnamnet har ändrats och om en annan DNS-resolver åsidosätter Tailscales inställningar.

Behöver jag en subnet-router för att komma åt min hemserver?

Inte när Tailscale är installerat direkt på den servern. Använd dess Tailscale-IP eller MagicDNS-namn. En subnet-router behövs för att nå andra LAN-enheter som inte kör Tailscale.

Kan en brandvägg blockera Tailscale även när noden är online?

Ja. Tailscale-klienten kan ansluta till tailnet medan operativsystemets brandvägg fortfarande blockerar SSH, webben, SMB eller en annan applikationsport som kommer via Tailscale-gränssnittet.

Betyder en DERP-anslutning att Tailscale är trasigt?

Nej. DERP är en krypterad reservlösning när en direkt anslutning inte kan upprättas. Det kan lägga till fördröjning eller minska genomströmningen, men det ger fortfarande anslutning mellan enheterna.

Varför kan jag nå servern men inte en annan enhet på mitt hem-LAN?

Servern är en direkt Tailscale-nod, medan den andra enheten behöver en subnet-router. Kontrollera IP-vidarebefordran, annonserade rutter, ruttgodkännande, åtkomstregler och LAN-enhetens returväg.

Kan överlappande hem- och fjärrsubnät bryta Tailscale-åtkomst?

Ja. Om båda platserna använder samma privata subnet kan klienten skicka trafik till sitt nuvarande LAN istället för den fjärranslutna subnet-rutten. Föredra målets Tailscale-IP eller ändra en nätverks adressintervall.

Bör jag öppna portar på min router för att fixa Tailscale?

Vanligtvis inte. Bekräfta först nodstatus, brandväggsbeteende, applikationsbindning, åtkomstpolicy och om anslutningen är direkt eller vidarebefordrad. Att offentligt vidarebefordra applikationsporten är inget substitut för att hitta det faktiska Tailscale-felet.