Snowflake Standalone Server issue - multiple servers

I’ve been running multiple standalone snowflake servers for quite some time now. After recently reviewing a drop in traffic. I noticed a similar pattern across all of my installations, after updating the snowflake software on 2026/08/12 at 04:00, regular traffic is no longer flowing through these long running servers. After the update on 2026/08/12, I’m basically seeing zero traffic being passed. There are VERY sporadic traffic blips on one or two servers where some small amounts of traffic are being passed but for the most part my logs are now filled with:

In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0.00 KB/s).

My update process is as outlined on Tor Project | Compile Snowflake proxy from the source

kill -9 $(pidof proxy)
cd snowflake/
git pull
cd proxy
go build
nohup ./proxy >snowflake.log 2>&1 &

And this has been working on all servers for well over a year and a half. These servers are in different physical locations, on different hardware platforms, running Debian 13 or Ubuntu 26.04, located on different networks and are basically unrelated other than they run standalone snowflake proxies.

Example logs from a few servers - I have more but the pattern is exactly the same across them all:

Server 1:
2026/08/12 01:00:04 In the last 1h0m0s, there were 8 completed successful connections. Traffic Relayed ↓ 248033 KB (68.90 KB/s), ↑ 12056 KB (3.35 KB/s).
2026/08/12 02:00:04 In the last 1h0m0s, there were 8 completed successful connections. Traffic Relayed ↓ 1070983 KB (297.50 KB/s), ↑ 40787 KB (11.33 KB/s).
2026/08/12 03:00:04 In the last 1h0m0s, there were 7 completed successful connections. Traffic Relayed ↓ 32973 KB (9.16 KB/s), ↑ 3735 KB (1.04 KB/s).
2026/08/12 04:00:07 Proxy starting
2026/08/12 04:00:13 NAT type: open
2026/08/12 05:00:07 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0.00 KB/s).
2026/08/12 06:00:07 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0.00 KB/s).
2026/08/12 07:00:07 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0.00 KB/s).

Server 2:
2026/08/12 01:00:50 In the last 1h0m0s, there were 36 completed successful connections. Traffic Relayed ↓ 196559 KB (54.60 KB/s), ↑ 13037 KB (3.62 KB/s).
2026/08/12 02:00:50 In the last 1h0m0s, there were 34 completed successful connections. Traffic Relayed ↓ 148555 KB (41.27 KB/s), ↑ 9554 KB (2.65 KB/s).
2026/08/12 03:00:50 In the last 1h0m0s, there were 30 completed successful connections. Traffic Relayed ↓ 289978 KB (80.55 KB/s), ↑ 16708 KB (4.64 KB/s).
2026/08/12 04:00:30 Proxy starting
2026/08/12 04:01:12 NAT type: strict
2026/08/12 05:00:30 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0.00 KB/s).
2026/08/12 06:00:30 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0.00 KB/s).
2026/08/12 07:00:30 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0.00 KB/s).

Server 3:
2026/08/12 01:00:03 In the last 1h0m0s, there were 45 completed successful connections. Traffic Relayed ↓ 582806 KB (161.89 KB/s), ↑ 33424 KB (9.28 KB/s).
2026/08/12 02:00:03 In the last 1h0m0s, there were 39 completed successful connections. Traffic Relayed ↓ 188649 KB (52.40 KB/s), ↑ 13584 KB (3.77 KB/s).
2026/08/12 03:00:03 In the last 1h0m0s, there were 31 completed successful connections. Traffic Relayed ↓ 379997 KB (105.55 KB/s), ↑ 25692 KB (7.14 KB/s).
2026/08/12 04:00:04 Proxy starting
2026/08/12 04:00:06 NAT type: open
2026/08/12 05:00:04 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0 .00 KB/s).
2026/08/12 06:00:04 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0 .00 KB/s).
2026/08/12 07:00:04 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0 .00 KB/s).

Server 4:
2026/08/12 01:00:16 In the last 1h0m0s, there were 3 completed successful connections. Traffic Relayed ↓ 2482 KB (0.69 KB/s), ↑ 841 KB (0.23 KB/s).
2026/08/12 02:00:16 In the last 1h0m0s, there were 5 completed successful connections. Traffic Relayed ↓ 3659 KB (1.02 KB/s), ↑ 769 KB (0.21 KB/s).
2026/08/12 03:00:16 In the last 1h0m0s, there were 6 completed successful connections. Traffic Relayed ↓ 67734 KB (18.82 KB/s), ↑ 4253 KB (1.18 KB/s).
2026/08/12 04:00:20 Proxy starting
2026/08/12 04:01:00 NAT type: strict
2026/08/12 05:00:20 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0.00 KB/s).
2026/08/12 06:00:20 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0.00 KB/s).
2026/08/12 07:00:20 In the last 1h0m0s, there were 0 completed successful connections. Traffic Relayed ↓ 0 KB (0.00 KB/s), ↑ 0 KB (0.00 KB/s).

Wondering if anyone else is seeing the same?
Maybe I missed a memo somewhere? :slight_smile:

I don’t have an answer for you but have you tried running NAT type unrestricted

This is what I use and see traffic. Am running snowflake-proxy 2.13.1 (ff32ce45) on Ubuntu 22.04 LTS and I also compiled from source like you. I do this using a home internet connection. Am usually sitting at 12-14 concurrent open connections.

I don’t even know what NAT type: strict and NAT type: open are. Maybe something in the update when you did git pull
I scanned the source code and only see restricted, unrestricted, and unknown in version 2.13.1

Edited 2026/09/06:
Change of wording in version v2.14.1 - 2026-06-25
This probe system can classify the client’s interactive connectivity type as “strict” (restricted), “moderate”, or “open” (unrestricted).

curious bit is your own logs: traffic was fine, then Proxy starting at 04:00, and after that its zero even on boxes that report NAT type open. so its probably not “all of them flipped to strict” alone.

bobbybs point about unrestricted is worth trying (-nat-probe-server / whatever your build exposes, or just make sure youre not forcing restricted), but if open boxes also went silent after the same git pull id also:

  • check git log -1 / version string vs a known-good older commit from before 08/12 and run one proxy on that binary for a day
    • look for broker/SDP errors in the full log, not just the hourly summary line
      • confirm outbound UDP to the stun/broker endpoints still works (dns changes have killed snowflake for people before)
    • the open vs strict rename in newer builds is confusing vs the old unrestricted wording, but a clean open probe + zero success usually means broker path or the new poll behavior, not just NAT labeling.

In servers 1 and 3 which show NAT type: open (unrestricted) you are supposed to open a ports range with option -ephemeral-ports-range “start:end” in the startup command. I see you use nohup ./proxy >snowflake.log 2>&1 &

But servers 2 and 4 NAT type: strict (restricted) show no traffic either so that’s not it.

@BobbyB Snowflake v2.14.1 doesn’t include commit e152e8ada831031199dfab2a46a06d754b1018bf “Add 3 type interactive connectivity type support for broker, client, and proxy”, note that Tor team has not bumped the version, here is the link to v2.14.1:

@Throughget Please use older snowflake before Tor team deploys the new version of snowflake broker.

You may see Error polling broker: remote returned status code 400 if you pass -verbose option

I’ve never seen any instructions for going back to an older version. My way would be to just copy the directory to somewhere else before doing an update.

What I read here does add a bit of strength to the old saying “if it ain’t broke don’t fix it”.

Seems @Throughget would have been OK without the update.

Confirmed. Broker deployment status=Needs Triage

It appears this error is specific to the broker deployment for v2.14.1

Currently, in v2.14.0, the broker is functioning for both snowflake servers.

I was going to give this update a try but after reading all this I changed my mind. I see nothing in it which applies to my running proxy.

Finally had some time to test this. Indeed switching back to v2.14.0 resolved the issue.

With 2.14.1 here’s a sample snippet of what would happen:
...
2026/09/17 17:15:47 NAT check: WebRTC: OnConnectionStateChange: connecting
2026/09/17 17:15:48 NAT check: WebRTC: OnConnectionStateChange: connected
2026/09/17 17:15:48 WebRTC: DataChannel.OnOpen
2026/09/17 17:15:48 WebRTC: DataChannel.OnClose
2026/09/17 17:15:48 NAT check: WebRTC: OnConnectionStateChange: closed
2026/09/17 17:15:48 NAT Type measurement: unknown -> open
2026/09/17 17:15:48 NAT type: open
2026/09/17 17:15:48 no remote address given in websocket
2026/09/17 17:15:49 Connected to relay: wss://snowflake.torproject.net/
2026/09/17 17:15:49 Error polling broker: remote returned status code 400
2026/09/17 17:15:53 NAT check: WebRTC: dc.Close()
2026/09/17 17:15:54 Error polling broker: remote returned status code 400
2026/09/17 17:15:59 Error polling broker: remote returned status code 400
2026/09/17 17:16:04 Error polling broker: remote returned status code 400

then just repeaed status code 400 errors and no traffic would be passed.

switching to v2.14.0
...
2026/09/17 17:23:19 New Data Channel snowflake-
2026/09/17 17:23:19 Connection successful
2026/09/17 17:23:19 Data Channel snowflake-
2026/09/17 17:23:20 Connected to relay: wss://02.snowflake.torproject.net/
2026/09/17 17:23:33 Poll interval set to 5s
2026/09/17 17:23:48 Poll interval set to 5s
2026/09/17 17:24:03 Poll interval set to 5s
2026/09/17 17:24:24 Received offer from broker:

2026/09/17 17:24:24 Generating answer...
2026/09/17 17:24:24 Answer:

2026/09/17 17:24:27 New Data Channel snowflake-
2026/09/17 17:24:27 Connection successful
2026/09/17 17:24:27 Data Channel snowflake- open
2026/09/17 17:24:28 Connected to relay: wss://02.snowflake.torproject.net/
2026/09/17 17:24:40 Proxy starting
2026/09/17 17:24:41 NAT type: unrestricted
2026/09/17 18:24:40 In the last 1h0m0s, there were 23 completed successful connections. Traffic Relayed ↓ 616165 KB (171.16 KB/s), ↑ 65673 KB (18.24 KB/s).
2026/09/17 19:24:40 In the last 1h0m0s, there were 29 completed successful connections. Traffic Relayed ↓ 324435 KB (90.12 KB/s), ↑ 45961 KB (12.77 KB/s).

Success! Traffic is again being relayed.

I guess the real issue is if people are updating (like myself) as suggested in the documentation, how many other people is this affecting?

Now, I’ll have to downgrade all of my other relays to get them working again. It’s a shame an automatic update broke this as it takes steps to work-around it and then it will take more to put things back once it’s resolved.

Interesting to know. So you got burnt with automation.

I don’t spend much time on Git so how did you go back one version or how do you you select a specific version like 2.14.0 instead of the latest. I’ve only done the pull twice in the last year and a half.

Like you, I wonder how many operators are spinning those proxy wheels for nothing.

You can do a git checkout v2.14.0, then do a go build.

Automation has it’s benefits and drawbacks, it’s been working to keep my relays operational and up to date for quite some time with no intervention - but then stuff like this happens and it does make you think twice.

I’ll to keep my eye on this thread to see if you post more info and in the meantime do a bit of experimenting on a test system.

We have different needs. You seem to be on servers using unlimited capacity on the command line and probably have high symmetric bandwidth.

I’m on a home connection with an asymmetric bandwidth of 10/30 and I use -capacity 16 on startup to cap the number of connections. Have to keep some for myself.
I’m happily at ~13-14 current connections.

Edited later:
For anyone listening that should be: git checkout v2.14.0, then do a go build after doing git pull. My repository was still on v2.13.1
Compiled v2.14.0. Will wait to see if there are more issues before putting into production.