I think you could try to use curl instead of wget or try this command wget -O docker-compose.yml \ https://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/raw... If this command doesn't work, you are probably IP Blocked. On Sun, Aug 23, 2026 at 1:27 PM John Thompson via tor-relays - tor-relays at lists.torproject.org < tor-relays_at_lists_torproject_org_iiuokcebki@simplelogin.co> wrote:

Repeated blacklisting while running a tor relay has persuaded me to try a snowflake proxy instead. I want to run a stand-alone proxy on Almalinux-9.8. Following the instructions on https://community.torproject.org/relay/setup/snowflake/standalone/docker/,

I have installed docker, but cannot complete the next step, downloading the docker-compose.yml configuration file:

$ wget -O docker-compose.yml

https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... --2026-08-21 <https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/raw/main/docker-compose.yml?ref_type=heads--2026-08-21> 09:17:57--

https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... Resolving gitlab.torproject.org (gitlab.torproject.org)... 2620:7:6002:0:266:37ff:feb8:3489, 204.8.99.149 Connecting to gitlab.torproject.org (gitlab.torproject.org)|2620:7:6002:0:266:37ff:feb8:3489|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2026-08-21 09:17:57 ERROR 403: Forbidden.

Is there a fix?

--

-John Thompson (johndthompson@gmail.com) Appleton WI USA

_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org

On 8/23/26 06:49, Laur via tor-relays wrote:

I think you could try to use curl instead of wget or try this command

wget -O docker-compose.yml \ https://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake- proxy/raw/main/docker-compose.yml <https://gitlab.torproject.org/tpo/ anti-censorship/docker-snowflake-proxy/raw/main/docker-compose.yml>

If this command doesn't work, you are probably IP Blocked.

curl does manage to download the docker-compose.yml file. In the meantime, I noticed that tor-snowflake is also available as a snap package. Is there an advantage in using one or the other, or are they reasonably identical? Are there router port settings I should change to accommodate tor-snowflake? When I ran a tor relay, I opened ports to forward tor traffic to the machine running the relay. Does tor-snowflake need similar port forwarding? -- -John (JohnDThompson@gmail.com) Appleton, WI USA

Hi, Yes, Tor's GitLab is rate limiting access[1]. You can manually create the docker-compose file as suggested by Mike or, alternatively, you can download it using 'wcurl' or 'curl': $ wcurl https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... I'll update the Snowflake standalone docs. Thank you for running a snowflake proxy and reporting this issue. Gus [1] https://lists.torproject.org/mailman3/hyperkitty/list/tor-project@lists.torp... On Sun, Aug 23, 2026 at 01:54:35PM +0200, Mike Dylan Poppelaars via tor-relays wrote:

I ran into the same 403 problem when trying to download the docker-compose.yml file with wget.

It seems to be caused by the anti-DoS protection on Tor’s GitLab rather than by AlmaLinux or Docker itself.

What worked for me was simply creating the compose file manually instead of downloading it:

*** services:     snowflake-proxy:         network_mode: host         image: containers.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake:latest         container_name: snowflake-proxy         restart: unless-stopped         # For a full list of Snowflake Proxy CLI parameters see         # https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...         #command: [ "-ephemeral-ports-range", "30000:60000" ]     watchtower:         image: nickfedor/watchtower         container_name: watchtower         volumes:           - /var/run/docker.sock:/var/run/docker.sock         command: snowflake-proxy ***

I then ran:

*** docker compose config docker compose up -d snowflake-proxy ***

and the Snowflake proxy started successfully.

So if you’re seeing the same 403, I’d suggest skipping the wget step for now and creating the file by hand. I tried this on AlmaLinux 9.8 and it works.

Also opening the link with a normal browser works after waiting for 5 seconds, that's how I got the file.

~ Mike

On 21.08.2026 16:24, John Thompson via tor-relays wrote:

...

Repeated blacklisting while running a tor relay has persuaded me to try a snowflake proxy instead. I want to run a stand-alone proxy on Almalinux-9.8. Following the instructions on https://community.torproject.org/relay/setup/snowflake/standalone/docker/, I have installed docker, but cannot complete the next step, downloading the docker-compose.yml configuration file:

$ wget -O docker-compose.yml https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... --2026-08-21 09:17:57-- https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... Resolving gitlab.torproject.org (gitlab.torproject.org)... 2620:7:6002:0:266:37ff:feb8:3489, 204.8.99.149 Connecting to gitlab.torproject.org (gitlab.torproject.org)|2620:7:6002:0:266:37ff:feb8:3489|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2026-08-21 09:17:57 ERROR 403: Forbidden.

Is there a fix?

_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org

-- The Tor Project Community Team Lead

Hi, Yes, that is not unusual. Snowflake proxies only serve users connecting through Snowflake, so traffic can be considerably lower and more intermittent than on a Tor relay. One thing to check is the NAT type reported in the log. unrestricted is preferable; a restrictive NAT can limit which clients can connect. Snowflake does not require a fixed forwarded port, but firewall/NAT settings can still affect WebRTC connectivity. If the proxy has unrestricted NAT, runs continuously, and isn’t bandwidth-limited, there is probably little else to tune as far as I know. Best, Mike On 25.08.2026 02:48, John Thompson via tor-relays wrote:

On 8/23/26 09:16, Laur via tor-relays wrote:

...

The snap package and the docker one are identical.

For port forwarding, Snowflake uses WebRTC so no, port forwarding is not needed.

Good to know; thanks! I have the snap package installed and running now.

Another question: perusing the tor-snowflake log file, it seems that the number of connections and amount of data transferred through tor-snowflake is substantially less than what I was seeing when I ran a tor relay. Is this to be expected, or is there something I can tweak to improve matters?

For Snowflake to report unrestricted, inbound UDP must be able to reach the proxy. One approach is to give Snowflake a defined UDP range with|-ephemeral-ports-range|and then allow/forward that same range through both the host firewall and the router. It is recommended either forwarding an appropriate UDP port range to the proxy or placing the host outside NAT. Roger gives|-ephemeral-ports-range 40000:45000|with the same UDP range allowed as a working setup: https://forum.torproject.org/t/tor-relays-running-a-snowflake-bridge-on-deba... <https://forum.torproject.org/t/tor-relays-running-a-snowflake-bridge-on-debain/20644> If there is double NAT, the forwarding has to work through every NAT layer. If the ISP is using CGNAT, unrestricted IPv4 may not be possible without a public IPv4 address. On 25.08.2026 14:43, John Thompson via tor-relays wrote:

On 8/25/26 03:02, Mike Dylan Poppelaars via tor-relays wrote:

...

One thing to check is the NAT type reported in the log. unrestricted is preferable; a restrictive NAT can limit which clients can connect. Snowflake does not require a fixed forwarded port, but firewall/NAT settings can still affect WebRTC connectivity.

The tor-snowflake log shows "NAT type: restricted" but so far I have not been able to determine what router, firewall, i[tables or nftables settings or combination of settings will allow for unrestricted NAT.

On 8/25/26 10:35, Mike Dylan Poppelaars via tor-relays wrote:

For Snowflake to report unrestricted, inbound UDP must be able to reach the proxy. One approach is to give Snowflake a defined UDP range with - ephemeral-ports-range and then allow/forward that same range through both the host firewall and the router.

It is recommended either forwarding an appropriate UDP port range to the proxy or placing the host outside NAT. Roger gives -ephemeral-ports- range 40000:45000 with the same UDP range allowed as a working setup:

Thanks. It isn't clear to me which tor-snowflake config file needs to be modified. I added "-ephemeral-ports-range 40000:45000" to the "ExecStart" line in /etc/systemd/system/snap.tor-snowflake.snowflake.service, ran "systemctl reload-daemon", ran "sudo snap restart tor-snowflake", opened ports 40000-45000 in the firewall, restarted firewalld, opened ports 40000-45000 UDP on the router to be forwarded to the snowflake machine, but it hasn't made a difference. NAT is still reported as "restricted." -- -John (JohnDThompson@gmail.com) Appleton, WI USA

On 8/25/26 15:40, Mike Dylan Poppelaars via tor-relays wrote:

Maybe someone else has better ideas for this issue because I don't anymore. What is possible is that the snap package doesn't support adding the -ephemeral-ports-range flag. Or maybe it's really just the NAT behavior of your router.

Yeah, it's frustrating. I appreciate your efforts. I console myself by thinking that ANY tor throughput is better than no tor throughput. Snowflake is working, and that's something. -- -John (JohnDThompson@gmail.com) Appleton, WI USA

Hi there, did you check your firewall/router-appliance for Static Port Mapping? For security reasons, some firewalls/routers have random port assignment of the external NAT-Ports. Means, a random source port will be selected. I had to change this for some Deutsche Telekom VoIP Costumers and that did the trick. For an OPNSense Firewalls as example, go to Firewall -> Source NAT -> Create New Rule Interface = WAN, Source = Your Proxy IP, Destination = any, Static Port = enabled, Translate Address = Interface Address If you don't have a professional router/firewall, then this setting might not be available for you. I could further assist if you need help with OPN/PFSense or Sophos based Firewall Setups. Furthermore, I can warmly recommend the Browser Plugin from SnowFlake. Setup in seconds and still modest traffic without any network setup. Best regards and have a nice weekend! Joker -----Ursprüngliche Nachricht----- Von: Cecylia Bocovich via tor-relays [mailto:tor-relays@lists.torproject.org] Gesendet: Donnerstag, 27. August 2026 23:14 An: tor-relays@lists.torproject.org Cc: Cecylia Bocovich Betreff: [tor-relays] Re: Snowflake throughput (was Re: Re: Snowflake setup fail) On 8/25/26 3:51 PM, John Thompson via tor-relays wrote:

Thanks. It isn't clear to me which tor-snowflake config file needs to be modified. I added "-ephemeral-ports-range 40000:45000" to the "ExecStart" line in /etc/systemd/system/snap.tor-snowflake.snowflake.service, ran "systemctl reload-daemon", ran "sudo snap restart tor-snowflake", opened ports 40000-45000 in the firewall, restarted firewalld, opened ports 40000-45000 UDP on the router to be forwarded to the snowflake machine, but it hasn't made a difference. NAT is still reported as "restricted."

You can try the following steps to check that your port forwarding is working correctly: - Run on the same machine as your snowflake proxy a simple TCP server to listen for incoming connections to a port in that range: nc -l 40000 - From *another network*, try to connect to your IP and port nc [IP] 40000 If IP forwarding is set up correctly, you should be able to send and receive messages on that connection. Thank you for running a Snowflake proxy! Proxies with restrictive NATs are still very valuable to the network. _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org