What Should You Check When Tailscale Cannot Reach Your Home Server?

When Tailscale cannot reach your home server, the failure is not always inside the Tailscale network itself. The server may be offline, the device name may not resolve, an access rule may reject the connection, the operating system firewall may block the service, or the application may be listening only on localhost.

The fastest way to find the cause is to troubleshoot in layers. First confirm that both Tailscale nodes are online. Then test the server’s raw Tailscale IP, separate basic node connectivity from application access, and only move into subnet routing or DERP troubleshooting when the symptoms actually point there.

Start by Identifying Which Layer Is Failing

A common troubleshooting mistake is treating every timeout as the same problem. A home server that appears offline in the tailnet is different from a server that responds to Tailscale ping but refuses an SSH or web connection.

Tailscale provides the private network path between devices, but the final service still depends on the server operating system, firewall, listening port, application configuration, Docker networking, and access policy. Fixing the wrong layer can create additional problems without restoring the connection.

Before changing anything, write down the exact symptom. Check whether the server appears online, whether its Tailscale IP responds, whether its MagicDNS name resolves, and whether the specific application port accepts a connection.

Confirm That Both Tailscale Nodes Are Online

Start with the two devices involved in the connection. The remote laptop or phone must be connected to the tailnet, and the home server must also be online under the expected account, tag, or device identity.

On a Linux server, check the Tailscale service and run tailscale status. On desktop systems, verify that the client is connected rather than paused, logged out, or waiting for authentication. A server that failed to start Tailscale after a reboot cannot be fixed by changing DNS or application ports.

Also check whether the server appears under the expected device name and Tailscale IP. If the node is offline, fix the service, login state, system startup behavior, or client version before troubleshooting anything above the network layer.

Use the Raw Tailscale IP Before Testing a Hostname

A hostname adds DNS resolution to the connection path. If you begin with a server name such as homeserver or nas-device, you cannot immediately tell whether the failure comes from networking or name resolution.

Find the server’s Tailscale IPv4 address, normally in the 100.x.x.x range, and try that address directly. When LAN routes, exit nodes, or overlapping subnets complicate the path, it is especially useful to test the device’s Tailscale IP before its private LAN address.

If the raw IP works but the hostname does not, basic node connectivity is probably healthy. Move to MagicDNS and client DNS settings instead of reinstalling Tailscale or changing the router.

If the IP Works but the Name Fails, Check MagicDNS

MagicDNS lets devices use readable machine names instead of remembering Tailscale IP addresses. When it works, a device named home-server can be reached through that name from another device in the same tailnet.

The feature creates automatic device names inside the tailnet, but successful resolution still depends on the device being connected and the client accepting the tailnet’s DNS configuration. Local DNS filters, enterprise security tools, custom resolvers, or stale cached records can interfere.

Compare the short hostname, the full tailnet name, and the raw Tailscale IP. If only the names fail, check whether MagicDNS is enabled, whether the machine was renamed, and whether another DNS product is overriding the resolver configuration.

Separate Tailscale Connectivity From Application Connectivity

A successful node-to-node connection does not prove that every service on the server is reachable. You may be able to ping the Tailscale IP while SSH, Jellyfin, a dashboard, SMB, or a Docker web interface still times out.

That usually means the Tailscale path exists but the application layer is refusing or missing the connection. The service may be stopped, listening on another port, bound to the wrong interface, blocked by the server firewall, or unpublished from its container.

Test the exact destination you need, such as 100.x.x.x:22 for SSH or http://100.x.x.x:8080 for a web service. If the node responds but the port does not, stop troubleshooting MagicDNS and DERP until the server-side service is verified.

Check Whether the Service Is Listening on the Right Interface

An application can run normally on the home server and still be unreachable from every other device. This happens when the service listens only on 127.0.0.1, which accepts connections from the server itself but not through its LAN or Tailscale interfaces.

A service listening on 0.0.0.0 accepts IPv4 traffic on all available interfaces, while a service can also be bound explicitly to the server’s LAN address or Tailscale address. The correct choice depends on whether the service should be reachable from the LAN, tailnet, or only through a local reverse proxy.

Do not automatically change every service to 0.0.0.0. Confirm the intended access path first, then use firewall rules and application authentication to limit who can reach the port.

The Server Firewall May Be Blocking Tailscale Traffic

A service can work through the home server’s LAN IP but fail through its Tailscale IP because the operating system treats the Tailscale interface as a separate network path. LAN rules do not always apply to traffic arriving through tailscale0.

Linux systems may use UFW, firewalld, iptables, or nftables. Windows may classify the Tailscale adapter differently from the home LAN. Broader network firewalls can also prevent direct UDP connections and force traffic onto relayed paths. The relevant check is whether your firewall permits the intended Tailscale connection path.

Do not disable the entire firewall as a permanent fix. Allow only the required service port from the Tailscale interface, selected Tailscale addresses, or an appropriate tailnet policy. Then retest the application directly.

Check Access Policies, Grants, Tags, and Device Identity

If one Tailscale device can reach the home server while another cannot, the difference may be intentional policy rather than a network failure. Access can depend on the user, source device, destination tag, protocol, and port.

A server tagged for infrastructure access may not accept traffic from a personal device unless the policy permits that combination. A rule that allows SSH does not necessarily allow the web dashboard on another port, and a shared device may have different permissions from a device owned by the same user.

Review the source identity, destination identity, server tags, and requested port together. A temporary broad rule can help isolate a policy issue, but replace it with the narrowest correct rule after testing.

A Direct Home Server Does Not Need a Subnet Router

If Tailscale is installed directly on the home server, use the server’s own Tailscale IP or MagicDNS name. A subnet router is not required to reach that machine.

Subnet routers solve a different problem: they provide access to devices that do not run Tailscale themselves, such as a printer, camera, older NAS, smart-home device, or another machine on the home LAN.

Adding subnet routing to a simple direct-node problem creates more places for the connection to fail. First prove that the Tailscale client on the home server is reachable. Only troubleshoot advertised LAN routes when the actual target sits behind that server.

Subnet Routing Requires a Complete Routing Chain

When the target is a LAN device without Tailscale, the subnet router must do more than appear online. It has to receive traffic from the tailnet, forward it into the home LAN, and allow the response to return.

A working setup normally requires IP forwarding on the routing device, advertised subnet routes, route approval, matching access controls, and client-side route acceptance where required. The purpose is to advertise a private subnet through a gateway so tailnet devices can reach machines that do not run the client.

If the route is visible but traffic fails, check each stage separately. Confirm the correct subnet was advertised, verify that it was approved, inspect the forwarding firewall, and make sure the LAN device has a valid return path.

Overlapping Private Subnets Can Send Traffic the Wrong Way

Many home, office, and hotel networks reuse addresses such as 192.168.1.0/24. If your current Wi-Fi and your home subnet use the same range, the operating system may treat the destination as local instead of sending it through Tailscale.

This creates a confusing symptom: the direct Tailscale IP of the server works, but its home LAN IP does not. The request may be going to the current network rather than the remote subnet router.

Use the target’s Tailscale IP whenever possible. If subnet access is necessary, consider changing one LAN to a less common private range or applying a routing design that handles the overlapping networks deliberately.

An Exit Node Can Change Access to the Current LAN

If the client device is using a Tailscale exit node, its route selection differs from a normal tailnet connection. Access to nearby LAN devices may be blocked unless local network access is explicitly allowed.

This matters when troubleshooting from a laptop connected to hotel, office, or home Wi-Fi while also using an exit node. A failure to reach a private LAN address may come from exit-node behavior rather than from the home server.

Test without the exit node, or enable LAN access only when you trust the local network. Do not enable broad local access automatically on unknown public Wi-Fi.

Docker Adds Another Port and Interface Boundary

A host service such as SSH may work through Tailscale while a Docker application on the same server fails. That usually points to container networking rather than node connectivity.

Check whether the container is running, whether the application listens inside the container, and whether its port is published to the host. A Compose mapping such as 8080:80 exposes container port 80 through host port 8080, while a port bound only to 127.0.0.1 may remain inaccessible through the Tailscale IP.

Also check reverse-proxy routes, host networking, Docker firewall rules, and whether the application itself permits connections from non-LAN addresses. Test the host port directly before debugging higher-level domains or certificates.

DERP Usually Explains Slowness More Than Complete Failure

Tailscale tries to create direct connections between devices. When NAT behavior or firewall restrictions prevent that, it can use a relay path instead.

DERP provides an encrypted relay fallback when direct connectivity fails. The relay forwards already encrypted traffic and can connect devices across difficult IPv4, IPv6, NAT, and firewall combinations.

A DERP path often works with more latency or lower throughput, so it is a strong suspect when SSH feels laggy or file transfers are slow. If the connection does not work at all, first check node status, access policy, local firewall, application port, and bind address.

Use Connection Diagnostics Before Changing the Router

Commands such as tailscale ping help separate a node path from an application path. A successful result proves more than a failed browser tab because it tests connectivity without relying on the application’s port, proxy, or certificate.

tailscale netcheck can help show UDP availability, NAT behavior, IPv4 or IPv6 connectivity, and nearby relay regions. These results are most useful when the connection works only through a relay or changes between networks.

Do not begin by adding public port forwarding to the home router. Tailscale is designed to work without exposing the home server’s application ports directly to the internet. Router changes should respond to a confirmed path problem, not replace the earlier diagnostic steps.

Restart and Update Only After You Know the Failing Layer

Restarting Tailscale can restore a failed daemon or stale client state, but repeated restarts are not a diagnosis. If the same failure returns after every reboot, the underlying issue is probably startup configuration, firewall policy, routing, or application binding.

Confirm that the home server starts Tailscale without an interactive desktop login and remains connected after reboot. Also compare client versions if one device behaves differently from the rest of the tailnet.

After an update or restart, repeat the same tests in the same order: node status, raw IP, hostname, Tailscale ping, and application port. A consistent test sequence shows which layer actually changed.

Follow One Troubleshooting Order

The fastest path is to move from the Tailscale node toward the application. Do not modify DNS, subnet routes, firewall rules, and Docker networking at the same time.

First confirm both nodes are online. Then test the raw Tailscale IP, followed by the MagicDNS name. Test the node path, then the application port. Only after those checks should you investigate the server firewall, bind address, access policy, Docker mapping, or subnet routing.

This order prevents a simple stopped service from turning into a complicated routing project. Each test should answer one question before you move to the next layer.

Final Takeaway

When Tailscale cannot reach your home server, start with the simplest distinction: can the two Tailscale nodes communicate, and can the application accept traffic? Confirm both nodes are online, test the raw Tailscale IP, and then test the MagicDNS name and exact service port.

If the node path works but the application does not, focus on the server firewall, listening interface, application settings, Docker port mapping, and access policy. If the target does not run Tailscale, then move into subnet router configuration, route approval, IP forwarding, and overlapping subnet checks.

DERP relay paths usually explain slower performance rather than complete failure. A consistent layer-by-layer test is more effective than reinstalling Tailscale, disabling the firewall, or adding public port forwarding without knowing where the connection stops.

FAQ

Why can I ping my Tailscale server but not open its web interface?

The node-to-node connection is working, but the web service may be stopped, listening on another port, bound only to localhost, blocked by the server firewall, or not published from its Docker container.

Why does the Tailscale IP work but the server name does not?

This points to MagicDNS or another DNS configuration issue. Check whether MagicDNS is enabled, whether the machine name changed, and whether another DNS resolver is overriding Tailscale’s settings.

Do I need a subnet router to access my home server?

Not when Tailscale is installed directly on that server. Use its Tailscale IP or MagicDNS name. A subnet router is needed for reaching other LAN devices that do not run Tailscale.

Can a firewall block Tailscale even when the node is online?

Yes. The Tailscale client can connect to the tailnet while the operating system firewall still blocks SSH, web, SMB, or another application port arriving through the Tailscale interface.

Does a DERP connection mean Tailscale is broken?

No. DERP is an encrypted fallback when a direct connection cannot be established. It can add latency or reduce throughput, but it still provides connectivity between the devices.

Why can I reach the server but not another device on my home LAN?

The server is a direct Tailscale node, while the other device needs a subnet router. Check IP forwarding, advertised routes, route approval, access rules, and the LAN device’s return path.

Can overlapping home and remote subnets break Tailscale access?

Yes. If both locations use the same private subnet, the client may send traffic to its current LAN instead of the remote subnet route. Prefer the target’s Tailscale IP or change one network’s address range.

Should I open ports on my router to fix Tailscale?

Usually not. First confirm node status, firewall behavior, application binding, access policy, and whether the connection is direct or relayed. Publicly forwarding the application port is not a substitute for finding the actual Tailscale failure.