Help with P2P Routing in China

I use NB on macOS and Ubuntu. Latency used to be fine but either due to a version update or some Chinese change, the latency is becoming crazy. My home is 2km from my office, and I used to be able to SSH and nomachine in over NB. But in the last week or so latency is >700ms and ssh is basically unusable and nomachine too. I assume NB cannot find a P2P route now so goes through a US server thus the latency. Does anyone have advice how to improve P2P discovery in this case or at least know what route is being selected?

Could be that your office made the ports/firewall stricter, are you the IT admin or a user?

I’m a User. I’m also having problems connecting to a totally different site around 20km away (not the same admin) but still in my city. I think this may be GFW at the ISP level is starting to disrupt UDP traffic (as VPNs that use UDP are also starting to become unreliable). Is there a way to debug the “hops” or how netbird is routing between two peers to understand why I have >1s ping and lots of drops?

It appears netbird will start to fail here is china as traffic gets selectively disrupted. The GFW is targeting IPv4 and sadly Netbird doesn’t seem to support any form of IPv6 routing.

You could check with

However, after a certain point this becomes a routing/firewall question. And this is so deep of a level I woudn’t be able to assist you with that.

Thanks I will check the troubleshooting steps. It is clear my connection is being relayed, my detailed log for from home to my work server shows:

Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address: rels://streamline-vl-nrt-0.relay.netbird.io:443

I reinstalled my Zerotier client and on the same network using the Zerotier IPv6 route my ssh connection is like butter (the peer list shows DIRECT as the connection type, 10ms ping! compared to ~700ms Netbird). However I can also connect on IPv4 with low ping times so there is some other routing algorithm difference that is not dependent on IPv6.

I have also noticed recently I need to force netbird down && netbird up which can enable some local routes (so I am even having problems on the same local switch, where my local IP can connect (1ms ping) but netbird IPs do not respond at all…

Hm, even when both machines are in my office I am having issues. My laptop and my workstation (cog5) are on the same switch, but this is what I see in netbird status:

  {
        "fqdn": "cog5.cloud.lab",
        "netbirdIp": "100.112.1.5",
        "netbirdIpv6": "fd00:1:1::5",
        "publicKey": "xxx",
        "status": "Connected",
        "lastStatusUpdate": "2026-05-22T12:50:24.886837+08:00",
        "connectionType": "Relayed",
        "iceCandidateType": {
          "local": "",
          "remote": ""
        },
        "iceCandidateEndpoint": {
          "local": "",
          "remote": ""
        },
        "relayAddress": "rels://streamline-vl-nrt-1.relay.netbird.io:443",
        "lastWireguardHandshake": "2026-05-22T12:54:38+08:00",
        "transferReceived": 1620,
        "transferSent": 2140,
        "latency": 0,
        "quantumResistance": false,
        "networks": [
          "172.16.102.77/32",
          "172.16.102.30/32",
          "10.10.47.188/32"
        ]
      },

However when i ping (they are literally next to each other):slight_smile:

> ping 100.112.1.5
PING 100.112.1.5 (100.112.1.5): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
64 bytes from 100.112.1.5: icmp_seq=0 ttl=64 time=3007.013 ms
64 bytes from 100.112.1.5: icmp_seq=1 ttl=64 time=2001.812 ms
64 bytes from 100.112.1.5: icmp_seq=2 ttl=64 time=996.652 ms
64 bytes from 100.112.1.5: icmp_seq=3 ttl=64 time=1062.633 ms
64 bytes from 100.112.1.5: icmp_seq=4 ttl=64 time=234.692 ms

Zerotier runinng simultaneously is fine:

ping6 fd00::2
PING6(56=40+8+8 bytes) fd00::1 --> fd00::2
16 bytes from fd00::2, icmp_seq=0 hlim=64 time=28.834 ms
16 bytes from fd00::2, icmp_seq=1 hlim=64 time=1.433 ms
16 bytes from fd00::2, icmp_seq=2 hlim=64 time=1.844 ms
16 bytes from fd00::2, icmp_seq=3 hlim=64 time=1.749 ms
16 bytes from fd00::2, icmp_seq=4 hlim=64 time=1.653 ms
16 bytes from fd00::2, icmp_seq=5 hlim=64 time=1.860 ms
16 bytes from fd00::2, icmp_seq=6 hlim=64 time=1.718 ms

Aprt from netbird down; netbird up on both systems anything else I can try? Netbird 0.71.4 on the laptop and 0.71.2 on the workstation.

NetBird should be using your IPv6. Can you enable trace logs with:

netbird debug log level trace

then run:

netbird down

netbird up

After that, you can check the logs for local candidates:

sudo grep -i candidate /var/log/netbird/client.log | grep '<public key of cog5.cloud.lab>'

See if you are receiving IPv6 candidates with the OnRemote Candidate and discovering local candidates as well.

Share your findings with us.

Also, can you check the latency to the relay you are using?


ping streamline-vl-nrt-1.relay.netbird.io

traceroute -d streamline-vl-nrt-1.relay.netbird.io 

Sorry for my late reply to your prompt and helpful response. I didn’t get a chance to log this when it was broken. Since May I’ve just been using Zerotier. However I had time to check today and I’m happy to report that the P2P negotiation problems have been solved, at least with 0.74.7 running on both ends. Both Netbird and Zerotier are competitive in terms of ping latency on both IPv4 and IPv6. Super!!! :heart_eyes:

BTW, is the default for this netbird debug log level info?

Hm, it appears the netbird connectivity is much more variable. I am now back to a relayed connection only, some network variability somewhere stopping Netbird but not affecting Zerotier.

BTW, the ping to relay:


ping streamline-vl-nrt-1.relay.netbird.io
PING streamline-vl-nrt-1.relay.netbird.io (45.32.10.34): 56 data bytes
64 bytes from 45.32.10.34: icmp_seq=0 ttl=51 time=217.866 ms
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 45.32.10.34: icmp_seq=3 ttl=51 time=245.051 ms

--- streamline-vl-nrt-1.relay.netbird.io ping statistics ---
5 packets transmitted, 2 packets received, 60.0% packet loss
round-trip min/avg/max/stddev = 217.866/231.459/245.051/13.592 ms

Traceroute times out?

raceroute to streamline-vl-nrt-1.relay.netbird.io (45.32.10.34), 64 hops max, 40 byte packets
 1  router.ctc (192.168.2.1)  23.253 ms  3.864 ms  3.285 ms
 2  192.168.71.1 (192.168.71.1)  21.674 ms  6.833 ms  7.397 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
31  * * *
32  * * *
33  * * *
34  * * *
35  * * *
36  * * *
37  * * *
38  * * *
39  * * *
40  * * *
41  * * *
42  * * *
43  * * *
44  * * *
45  * * *
46  * * *
47  * * *
48  * * *
49  * * *
50  * * *
51  * * *
52  * * *
53  * * *
54  * * *
55  * * *
56  * * *
57  * * *
58  * * *
59  * * *
60  * * *
61  * * *
62  * * *
63  * * *
64  * * *