I keep missing the test and becoming restricted.
2026/03/09 17:19:34 Test WebRTC connection with NAT check probe server timed out. This means our NAT is restricted.
2026/03/09 17:19:34 NAT Type measurement: unrestricted -> restricted
2026/03/10 17:19:55 Test WebRTC connection with NAT check probe server timed out. This means our NAT is restricted.
2026/03/10 17:19:55 NAT Type measurement: restricted -> restricted
Any news on this? Or is it just unlucky?
Seems it might be luck but 2 days in a row at the same time and it fails. Hmmmm.
Today:
2026/03/11 17:19:57 Test WebRTC connection with NAT check probe server established! This means our NAT is unrestricted!
2026/03/11 17:19:57 NAT Type measurement: restricted -> unrestricted
The server is not down. You would get a Error polling probe error if it was down.
But yes, I am pretty sure that the NAT checking is unreliable, it’s been the case for a long time. There have been a few MRs to try to fix that, but it didn’t completely go away apparently.
Looks like the problem is being addressed:
I did not get that error so it was just luck. The same time is because I use the default 24 hours.
So the test is unreliable then maybe a solution is to reschedule the test in 1 hour when unrestricted → restricted occurs since, in my mind, this is illogical. Once unrestricted is achived again then the proxy could revert to whatever -nat-retest-interval was.
My understanding is that by assigning an -ephemeral-ports-range you want the unrestricted state. I tried -nat-retest-interval 0 to turn it off but had an undesirable result when my IP changed for some reason.(DHCP lease time??) The proxy dropped all users and it went to this probe test and became restricted. It took a while for me to realize this. Not getting past 7 user connections was the clue.
Seems I was onto something.
I get why the probe test is done when you start up the proxy: to get that unrestricted state and register it with the broker but why does it need to be repeated by whatever time you set or default 24hrs. From what I understand you will never reach unrestricted state without opening ports.
From my post above the state changed to restricted at 2026/03/09 17:19:34.
From the broker’s point of view it must know my unrestricted state at 1 minute previous (17:18:34). Then why must it test it again at 17:19:34. Nothing has changed at my end.
I guess the periodic re-test is to cover cases where firewall rules/port forwarding rules or other changes made on a proxy’s machine do genuinely result in a different NAT type.
From the broker’s point of view it must know my unrestricted state at 1 minute previous (17:18:34).
From the log extracts you posted, the timeout in the probe test at 2026/03/09 17:19:34 seems to mean your proxy gets re-designated as “restricted” type even though nothing changed at your end. This may be a design flaw - i.e. if the single server probe test is prone to timeouts for reasons not associated with one’s NAT type, perhaps a number of unrestricted proxies are currently being incorrectly designated as “restricted”. I have not dived into the code to verify whether or not this may be the case, however, in the issue I linked to above @cecylia made this suggestion, which suggests it is a known issue:
Maybe we need to change our NAT behaviour discovery implementation to use multiple separate STUN servers instead of relying on one server to have implemented this feature correctly.
In the meantime I am using a 0s retest interval and simply check my logs when the proxy (re)starts to verify I get treated as “unrestricted”. I reboot my WAN interface regularly and haven’t seen the drop in connections you observed. In any case, it would be good to verify whether or not a new external IP for a standalone proxy does trigger a NAT type retest or otherwise impact how the broker assigns clients to it. @Shelikhoo can you perhaps answer this?
I have the answer to my question.
When an IP changes for whatever reason, while the proxy is up, it will do the probe test and you could get to this restricted state. If the test is set to 0, or did not exist, it will never test again to allow you to get to unrestricted state. I found this out as I stated above and went back to default 24hrs. I just never realised it was my answer until now.
I will mark this thread as solved since the issue is being looked at.
Edited later:
Too bad I ticked SOLUTION and got this thread closed
"perhaps a number of unrestricted proxies are currently being incorrectly designated as “restricted”
Yes, I greped my logs and it happened more than I thought. I’ll do like you and use a 0 retest interval and test on a boot or proxy restart. I have to be at the console anyway.
“In any case, it would be good to verify whether or not a new external IP for a standalone proxy does trigger a NAT type retest or otherwise impact how the broker assigns clients to it.”
IT DOES NOT. I looked at my logs and can confirm that a probe test does NOT occur when the IP changes by itself (without a boot or restart) as I mentioned in my post. It happened during a restart or boot and I did not catch it until 8 hours later. Soon after I reverted to the default 24 hours from 0.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.
Sorry for the late reply,
The STUN server update are there to help clients detect their NAT types, not proxy(which uses the probe server you have seen). This probe server try to see if the proxy can connect to it to determine the nat type.
Since the connection process is more or less a probabilistic process, sometime it may failed to make connection even if it should be able to.
There are some proposals to retest more often if an restricted nat type was detected(standalone proxy - NAT type not detected after OpenWrt router reboot (#40518) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab), this has yet to assigned as a priority.
You can test what is your actual nat type is with v2ray’s built-in tool(currently unreleased, require build from source): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40077#note_3366665 and see whether your network is really restricted or not.
I am aware you might have difficulty reply to me, if you have any issue, feel free to send me a private message or an email to shelikhoo@torproject.org .