WebTunnel Tor Bridge Setup Guide for 2026

WebTunnel uses a reverse proxy architecture. An nginx web server with a valid TLS certificate receives HTTPS connections from Tor clients. The request path includes a random-looking suffix that the nginx configuration recognizes as a WebTunnel path and passes to the WebTunnel server process. The WebTunnel server then hands the connection to the Tor process via ExtORPort.

From the outside, every connection looks like a client accessing a specific URL on a web server with a legitimate domain and certificate. The distinguishing feature - the random path suffix - is not visible in DPI analysis because it is inside the encrypted TLS payload. Active probing that simply connects to the server and follows the TLS handshake cannot distinguish a WebTunnel server from an ordinary HTTPS web application.

The requirement for a real TLS certificate and a registered domain name is the main additional overhead compared to obfs4. Operators need a domain name (any cheap domain works) and a Let's Encrypt certificate. The domain does not need to resolve to anything except the VPS IP, and it does not need to be associated with any real website content.

Register a domain name that does not obviously identify itself as Tor infrastructure. A generic-sounding domain like a tech company, personal portfolio, or cloud service works. Use a privacy-preserving registrar that accepts cryptocurrency and provides WHOIS privacy. The domain needs only one A record pointing to the VPS IP.

Install certbot and obtain a Let's Encrypt certificate:

apt install certbot python3-certbot-nginx
certbot certonly --nginx -d yourdomain.example.com --agree-tos --no-eff-email --email youranon@proton.me

Certbot creates a certificate valid for 90 days with automatic renewal when configured with a systemd timer or cron job. Verify the certificate with: openssl s_client -connect yourdomain.example.com:443 -servername yourdomain.example.com. The output should show the Let's Encrypt certificate chain and a valid expiry date in the future.

Build the WebTunnel server from the Tor Project repository:

git clone https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel.git
cd webtunnel/main/server
go build -o /usr/local/bin/webtunnel-server .

Create a systemd service unit for the WebTunnel server process. The server listens on a local port that nginx proxies to:

[Unit]
Description=WebTunnel Tor Transport Server
After=network.target

[Service]
User=debian-tor
ExecStart=/usr/local/bin/webtunnel-server -path /RANDOM_PATH_HERE -addr 127.0.0.1:15000 -extorport 127.0.0.1:5000
Restart=always
PrivateTmp=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Replace /RANDOM_PATH_HERE with a random-looking path such as /a7f8d9c2e1b3 that clients will use in their connection requests. This path must match what is configured in nginx and in the bridge line distributed to users.

Configure nginx to proxy WebSocket connections on the specific path to the WebTunnel server process:

server {
    listen 443 ssl http2;
    server_name yourdomain.example.com;
    ssl_certificate /etc/letsencrypt/live/yourdomain.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.example.com/privkey.pem;

    location /RANDOM_PATH_HERE {
        proxy_pass http://127.0.0.1:15000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }

    location / {
        return 200 "OK";
    }
}

The location / block returns a benign response for all other paths, making the server look like a minimal web application rather than a dedicated Tor transport server. Reload nginx with nginx -t && systemctl reload nginx. Verify the configuration accepts WebSocket connections with: curl -i --http2 https://yourdomain.example.com/RANDOM_PATH_HERE -H "Upgrade: websocket" -H "Connection: Upgrade".