Due to network fluctuations at 02:33:53 AM Beijing Time on June 3rd, the Magic Network Tool disconnected. Although the server network has now returned to normal, the connection has not been restored.
Due to network fluctuations at 02:33:53 AM Beijing Time on June 3rd, the Magic Network Tool disconnected. Although the server network has now returned to normal, the connection has not been restored.
Hello, I have checked the status of your Wonder Mesh device "Tano内网".
What we see on our end:
"Tano内网" is a device connected via Wonder Mesh, linked to Zeabur through a mesh tunnel (Tailscale). According to our monitoring, this device has been repeatedly disconnecting and reconnecting over the past day, rather than just a single outage:
When you posted (6/3 approx. 14:40), it fell right into the second outage period, which explains why you experienced "home network is back, but Zeabur still can't connect"—the local network was restored, but the mesh tunnel had not yet reconnected.
Such intermittent disconnections are usually caused by the device's network or the device itself (unstable home/NAT network, device entering sleep mode, Tailscale repeatedly reconnecting). Please troubleshoot on this device in order:
tailscale status
sudo systemctl restart tailscaled
limactl list
curl -fsSL https://cdn.zeabur.com/wonder/mesh-server-uninstall-linux.sh | sudo bash
curl -fsSL https://cdn.zeabur.com/wonder/mesh-server-uninstall-darwin.sh | bash
⚠️ For macOS, do not use sudo; the script must be executed as a regular user.
Related documentation:
Please let us know if this device is Linux or macOS, whether it usually enters sleep mode, and if it recovers after restarting Tailscale/reinstalling, so we can continue to follow up.
It's Linux, Ubuntu LTS 24 server. I suspect it's an issue with my upstream OpenWrt configuration, so I will investigate further. Also, besides UDP and TCP, does Tailscale use other protocols like QUIC?
Understood, it's Ubuntu 24 LTS Server. If you suspect an issue with the upstream OpenWrt configuration, you should focus on checking the firewall/NAT rules to ensure they allow UDP (especially UDP 41641 used by WireGuard) and TCP 443 (for DERP relay fallback).
Regarding the protocols used by Tailscale, the detailed documentation for the installation script covers this. You can refer to it here: https://zeabur.com/docs/zh-CN/wonder-mesh/install-script-details
If you need any assistance from our side during the troubleshooting process (such as checking connection status, logs, etc.), feel free to reply at any time.
Confirmed, the UDP issue was caused by my OpenWrt configuration. I am fixing it myself, thanks.
The network issue has been resolved, but reconfiguring the node has caused the old node to interfere with the new one, preventing connection. The old node is 100.64.2.227, and the current node is 100.64.2.228.
=== Zeabur Mesh Server Setup Complete === Mesh IP: 100.64.2.228 tano@tano:~$ sudo tailscale ip 100.64.2.228 fd7a:115c:a1e0::2e5
The following error keeps appearing in the client logs:
magicsock: derp-7 does not know about peer, removing route
And the offline node is still visible in tailscale status.
Please help confirm:
Thanks.
The latest error is: Jun 03 15:38:18 tano tailscaled[719]: Received error: PollNetMap: initial MapResponse lacked node
Tailscale client version: 1.98.4
Control URL:
https://wonder.zeabur.com
tailscaled logs:
RegisterReq: got response; machineAuthorized=true
but immediately after:
PollNetMap: initial MapResponse lacked Node
The node can authenticate successfully, but the control server returns an invalid initial MapResponse without a Node field, causing peer connectivity failure.
Please check the Headscale/Control Server logs and node records for user:
cfe6157e-2953-4b39-8cbe-b6f9e3ff4749
We have confirmed the following on our end:
machineAuthorized=true), it was not correctly added to the NetMap, which is why the PollNetMap: initial MapResponse lacked Node error is occurring.I have confirmed with the engineering team that your issue is caused by a synchronization mismatch between the client and the control plane. You need to clear both sides to resolve it. Please follow these steps:
curl -fsSL https://cdn.zeabur.com/wonder/mesh-server-uninstall-linux.sh | sudo bash
This will clear the old node records on both the client and the control plane, ensuring that re-registration won't conflict with any residual state.
Uninstall documentation: https://zeabur.com/docs/zh-CN/wonder-mesh/uninstall
Okay, sounds good.
This ticket has been inactive for a while. We will be closing it in 2 days if there is no new activity.