I do wonder how to quote the “$” correctly for systemd.
In moment I always get a systemd error for entries like this
ExecStart=/usr/bin/snowflake-proxy-udp -nat-retest-interval 1h -metrics -summary-interval 0h0m15s -metrics-port 9998 -broker ``https://snowflake-broker-gn1seck75hgtcmta.vwyjlwqyoh3sqmycg6wmi5
e732the58s3png-testing.v2fly.org:10443/`` -keep-local-addresses -allowed-relay-hostname-pattern \"$\"
in /etc/systemd/system/snowflake-proxy-udp.service
Update: “$$” make it.
For now 4 of 10 proxies are unrestricted NAT, but none of them get a connection.
I see the same result. No connections (except to the snowflake staging server - which I think might be the broker?). If I take the broker part out of the command the proxy makes connections as usual. ¯\_(ツ)_/¯
Do not take the broker part out, otherwise you’ll be making invalid connections on the main network.
The lack of connections could be explain by the fact that not many clients use the test network.
That was just an experiment 
I’m leaving it running properly for now.
There was no traffic when connecting to the staging server since there isn’t a lot of clients, and this is expected. It is not recommended to connect the production as when that happens, the test is not being conducted.
That being said, the proxy is supposed to correctly deal with older clients and don’t cause trouble even when used in the older network by design, so long as the server and broker is updated first(it didn’t).
Thanks @Shelikhoo So, if this test version is connected to the snowflake staging server, performs a nat probe every 24 hours and reports traffic hourly (in my case thats 0 up and 0 down) then everything is working as expected? If so, then I’m happy to leave it running. I have “older” proxy running on two other machines and turning over lots of traffic. 
I do wonder why my 10 common snowflakes are all unrestricted whereas the -udp variants at the same ip addresses respectively are all restricted except 1.
Yes, it is expected that it will initially have very little traffic. You could also try the client and see it in action for connecting via the staging snowflake network.
I guess I’d need a patched version of tor browser for mac in order to try the client. Not surprisingly I’ve had no success getting the linux version to run. Same for the tor expert bundle.
Of course, if the patch is going to be included in an upcoming release of tor browser, I’m happy to wait.
Actually I have build the patched version of tor-browser for macos. Please have a try: https://people.torproject.org/~shelikhoo/h1g7016nup4dv99f4u1nfoygzwsis0elqxyg/tor-browser-macos-tbb-nightly.2025.10.07.dmg
Just tried to open the dmg on a silicon mac running tahoe and an intel mac running mojave and both report a corrupt image 
It actually installs on the silicon mac but won’t even try to connect. The image won’t even open on intel.
Oh no…. I will have a check, thanks for reporting the issue… I do have a mac machine to test this.
nb when lauched I get a message from tor launcher indicating potential problems:
Tor exited during startup. This might be due to an error in your torrc file, a bug in Tor or another program on your system, or faulty hardware. Until you fix the underlying problem and restart Tor, Tor Browser will not start.
In the meanwhile I get between 0 and 5 connections per day at each -udp proxy.
In moment I’m trying to run a 3rd proxy at each system. That proxy is based on snowflake main repo + patched by https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/315.diff
The fun fact is that those proxies have a NAT being unrestricted, whereas the proxies based on shelikhoo / Snowflake · GitLab are almost restricted.
In moment I’m trying to get the metrics into my Grafana.
@Shelikhoo Maybe try to update your branch to get the NAT being fixed?
Update: The patching fails, so the MR has to be updated at least..
I tried the macos version, and was able to reproduce this issue. It seems the Tor binary bundled into it will immediately quit when being run.
I will try to build it again and see if anything improves.
Looking forward to it. \0/
Actually, I have asked the tor browser team yesterday, and was able to get a fix about this issue:
The root cause of the issue is that C-Tor requires code signing to run on more recent version of MacOS operating system. You can use this script to compete the local code signing to get it to work.
I have tried this myself and was able to get it to work.
I’m happy to report that I have a macOS test environment up and running. The client is on a device running 10.14.6 Mojave. I get a variety of NAT probe test results but mostly unrestricted. I see traffic on both restricted and unrestricted.
I also have TB nightly on a device running 10.15.7 Catalina. Not exactly screaming fast but it’ll do. Although I think cloudflare might still be acting up a bit 
Those are both on the same residential connection I use for ‘vanilla’ snowflake. Sadly, my isp bumped me onto a cgnat recently and I haven’t gotten around to calling them to get a proper ip address back. Sigh…