[tor-relays] Snowflake setup fail

Mailing Lists tor-relays
1

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 Tor Project | Docker setup, 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/snowflake/-/raw/main/docker-compose.yml?ref_type=heads
--2026-08-21 09:17:57-- https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/raw/main/docker-compose.yml?ref_type=heads
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

2

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

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

3

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
# proxy · main · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
#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 Tor Project | Docker setup, 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/snowflake/-/raw/main/docker-compose.yml?ref_type=heads
--2026-08-21 09:17:57-- https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/raw/main/docker-compose.yml?ref_type=heads
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?

4

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?

···

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 \
Sign in · GitLab proxy/raw/main/docker-compose.yml <The Tor Project · GitLab anti-censorship/docker-snowflake-proxy/raw/main/docker-compose.yml>

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

--

-John (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

5

The snap package and the docker one are identical.

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

···

On Sun, Aug 23, 2026 at 6:04 AM John Thompson via tor-relays - tor-relays at lists.torproject.org <tor-relays_at_lists_torproject_org_iiuokcebki@simplelogin.co> wrote:

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

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

6

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/snowflake/-/raw/main/docker-compose.yml?ref_type=heads

I'll update the Snowflake standalone docs.

Thank you for running a snowflake proxy and
reporting this issue.

Gus
[1] GitLab rate limiting deployed - tor-project - lists.torproject.org

···

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
# proxy · main · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
#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
> Tor Project | Docker setup,
> 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/snowflake/-/raw/main/docker-compose.yml?ref_type=heads
> --2026-08-21 09:17:57-- https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/raw/main/docker-compose.yml?ref_type=heads
> 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

7

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?

···

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.

--

-John (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

8

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?

9

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 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.

--

-John (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

10

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-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.

11

There was an issue with my last email, so here is it in plain text:

Hi,

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:

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.

Best,

Mike

···

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.

12

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."

···

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:

--

-John (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

13

Hi,

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.

Best,

Mike

···

On 25.08.2026 21:51, John Thompson via tor-relays wrote:

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."

14

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.

···

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.

--

-John (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

15

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.

···

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."

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

16

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

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

17

did you check your firewall/router-appliance for Static Port Mapping?

I have a fairly low-end consumer-level Netgear router and I don't see an
option for this.

Furthermore, I can warmly recommend the Browser Plugin from
SnowFlake. Setup in seconds and still modest traffic without any
network setup.

I have the Firefox snowflake plugin installed on my laptop and it
appears to be working. I installed tor-snowflake proxy package on the
desktop machine that used to run my tor relay, as it is connected 24/7.
It, too, appears to be working, but the log files suggest far fewer
connections and less data transferred than the tor relay it replaced, likely at least partly due to the restricted NAT it must use. I'd prefer to run the tor relay, but dealing with getting my IP address
blacklisted was getting tiresome.

At this point, I've resigned myself to running snowflake and accepting the lower performance as the price for not having to deal with the constant IP blacklisting of running a tor relay. Snowflake at least allows me to contribute something to the tor network.

···

On 8/28/26 08:24, ProSecureRelays via tor-relays wrote:

--

-John (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