A ZimaOS user believed Tailscale failed after its first launch because the app page displayed “service unavailable” and a phone could not reach home-server services. Container diagnostics showed a different result: Tailscale was running, the device was authorized, and the state and tunnel mounts were present.
The confirmed issue was the address used from the phone. The user was trying to reach a normal home LAN address without configuring subnet routing. Connecting to the service through the ZimaOS device’s Tailscale 100.x.x.x address worked.
The Tailscale Container Had Not Failed
The initial symptom suggested that the container stopped after a restart, but the collected state showed:
- The container status was running with exit code 0.
- Tailscale progressed from Starting to Running.
- The machine was authorized in the user’s tailnet.
- The persistent state directory was mapped into the container.
- The TUN device required by Tailscale was also mapped.
- The device received a Tailscale IPv4 address and could see peers.
This evidence separated a ZimaOS app-page or web-interface message from the health of the Tailscale daemon itself.
Why the First Diagnostic Attempts Showed Permission Denied
The terminal session used a normal ZimaOS user. The first Docker listing was run with elevated privileges, but later commands tried to access the Docker socket without them and therefore returned permission errors. Curly quotation marks copied from the forum also prevented some command substitutions from being interpreted correctly.
Those permission messages described the diagnostic session, not a Tailscale runtime failure. The later output obtained with the appropriate privileges showed that the container was healthy.
A Home LAN Address Is Not Automatically a Tailscale Address
An address such as 10.0.0.93 belongs to the home LAN. A phone connected remotely to the same tailnet does not automatically gain a route to every private LAN address.
Tailscale assigns each node its own address, commonly in the 100.x.x.x range. Tailscale’s official IP address documentation explains that these addresses identify devices inside the tailnet and remain separate from ordinary LAN addressing.
The Connection Method That Worked
The responder asked the user to connect to the application with the ZimaOS node’s Tailscale IP and the application’s own port:
http://TAILSCALE-IP:APP-PORTFor example, a service on port 8096 would use a URL shaped like:
http://100.x.x.x:8096The phone also needs to be signed in to the same tailnet and actively connected to Tailscale. The user confirmed that this address worked, which established that Tailscale itself was functioning.
When Subnet Routing Is Required
If the goal is to reach devices through their existing LAN addresses—such as 10.0.0.x—a device on that network must advertise the LAN subnet as a route, and the route must be approved according to the tailnet configuration.
This is a different setup from reaching the ZimaOS host directly through its own Tailscale IP. Follow Tailscale’s official subnet-router documentation before expecting normal LAN addresses to work remotely.
Why the App Page Could Still Say “Service Unavailable”
A web-interface availability check can fail even when the network daemon is running. In the source case, the decisive evidence was the running state, successful tailnet authorization, assigned Tailscale IP, visible peers, and a working remote service connection.
Changing random app ports, deleting Tailscale state, or repeatedly reinstalling the container would not address an incorrect destination address. Verify daemon health and the connection method before resetting a working identity.
Why the Working Connection Could Feel Slow
The final reply suggested that the connection might be using a DERP relay rather than a direct peer-to-peer path. Relayed Tailscale traffic can work correctly while delivering lower throughput or higher latency, depending on the networks, routers, and available relay region.
Slowness alone does not prove that the container is failing. First confirm whether the connection works and whether Tailscale reports a direct or relayed path, then investigate NAT and firewall behavior if performance matters.
A Safer Diagnostic Order
- Check whether the Tailscale container is running rather than relying only on the app-page status.
- Confirm that the ZimaOS node appears as authorized and online in the same tailnet as the phone.
- Identify the ZimaOS node’s Tailscale
100.x.x.xaddress through the Tailscale interface or admin console. - Connect to the target service using that Tailscale address and the service port.
- Configure subnet routing only if access through normal home LAN addresses is required.
- Investigate DERP relay use separately if the connection works but is slow.
ZimaOS Tailscale Connection FAQ
Does “service unavailable” prove that Tailscale stopped?
No. In this case, the container was running, authorized, and connected even though the app page showed that message.
Why did changing the Tailscale app port not help?
The problem was the destination address, not a normal web-app port conflict. The user needed the node’s Tailscale IP.
Which address should a remote phone use?
Use the ZimaOS node’s Tailscale 100.x.x.x address plus the application port, unless a subnet router has been configured for LAN addresses.
Why does a 10.0.0.x address fail over Tailscale?
It is a private home LAN address. Reaching that subnet remotely requires an advertised and approved subnet route.
Why can a working Tailscale connection be slow?
The connection may be relayed through DERP instead of using a direct peer-to-peer path.
