obfs4 Bridge Setup Guide for 2026 - Full Operator Walkthrough

Bridge operators have different requirements than exit relay operators. Bridges benefit most from IP addresses not yet known to censorship databases, stable uptime, and a data center jurisdiction that does not cooperate proactively with censorship authorities. Romania and Iceland consistently outperform other locations for bridge longevity because their IPs rotate less visibly through threat intelligence feeds and their data protection laws give providers legal cover to decline cooperation with speculative requests.

For raw resources, a 1 vCPU, 1 GB RAM, 20 GB NVMe VPS is entirely sufficient for running an obfs4 bridge at full capacity. You will not bottleneck on CPU because obfs4 uses AES-GCM acceleration available on any modern CPU via AES-NI. Network bandwidth is the real constraint. A modest bridge serves 50 to 150 users concurrently at 10 Mbps sustained. A high capacity bridge on a 500 Mbps port handles 1,000 or more simultaneous connections. AnubizHost Romania VPS Mini at $19.99/mo or Iceland VPS Start at $29.99/mo provide exactly this profile.

Choose a plan with at least 2 TB of monthly transfer. BridgeDB bridges typically consume 1 to 3 TB per month once they gain users through distribution channels. Pay with Bitcoin or Monero to avoid linking your real identity to the bridge IP. The bridge IP should have no prior hosting history tied to privacy or Tor - a fresh IP from a new deployment is the optimal starting point.

Start with a clean Debian 12 install. Add the official Tor Project repository to get the latest stable release rather than the older version in Debian default mirrors. Create the file at /etc/apt/sources.list.d/tor.list with the following content:

deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org bookworm main
deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org bookworm main

Fetch the signing key and install tor and obfs4proxy:

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null
apt update && apt install -y tor obfs4proxy deb.torproject.org-keyring

Verify the installed versions with tor --version and obfs4proxy --version. As of early 2026, Tor 0.4.8.x and obfs4proxy 0.0.14 are the stable releases. Any version significantly older than these should be considered for upgrade before production operation.

Edit /etc/tor/torrc. The minimal configuration for a public obfs4 bridge is shown below. Replace the port numbers and contact info with your own values. Use a port above 1024 to avoid requiring root for the tor process itself.

BridgeRelay 1
PublishServerDescriptor bridge
ExtORPort auto
ORPort 9001
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:443
ContactInfo anon-bridge-operator
Nickname MyObfs4Bridge
Log notice file /var/log/tor/notices.log

Using port 443 for the obfs4 listener is a deliberate choice. Many censored networks block all traffic except ports 80, 443, and 53. Placing obfs4 on 443 maximizes reachability without requiring additional firewall exceptions. The ORPort on 9001 handles internal Tor circuit traffic, not direct client connections, so it can use any port that is open on the server firewall.

Start tor with systemctl start tor and watch /var/log/tor/notices.log. After a few minutes you will see a line containing Your new bridge identity key fingerprint followed by your bridge fingerprint. Record this carefully. It is needed for distribution to users and for BridgeDB submission.

Open the ORPort and the obfs4 listener in your firewall. Using UFW:

ufw allow 9001/tcp comment "Tor ORPort"
ufw allow 443/tcp comment "obfs4 transport"
ufw enable

Verify with ufw status verbose that both rules appear. Then confirm from an external host that port 443 accepts connections. A simple test is nc -zv YOUR_SERVER_IP 443 from a machine outside the data center. A successful connection proves the port is open and reachable. Many new operators waste hours troubleshooting torrc before realizing the firewall silently drops incoming connections.

If your data center provides an external firewall or security group, open the same ports there. Cloud-style panels often have a separate layer of firewall rules that sit in front of the OS. Both layers must allow the same ports or bridges appear unreachable to BridgeDB health checks.

Public bridges submit their descriptor to the Tor directory authority automatically when PublishServerDescriptor is set to bridge. You do not need to manually submit; the process is automatic. Within 24 to 48 hours your bridge appears in BridgeDB and becomes available to users requesting bridges through bridges.torproject.org or via email to bridges@torproject.org.

For private bridges that you distribute manually to a trusted community, set PublishServerDescriptor 0. Users connect by entering the full bridge line including the obfs4 certificate parameter. You can find your complete bridge line in /var/lib/tor/pt_state/obfs4_bridgeline.txt after tor starts. The line looks like:

Bridge obfs4 YOUR_IP:443 FINGERPRINT cert=CERTIFICATE iat-mode=0

Private distribution through encrypted channels such as Signal groups, Matrix rooms with encryption, or XMPP with OMEMO gives the bridge a longer lifespan. Publicly listed bridges get burned faster as censors scrape BridgeDB or monitor Moat API responses. A mixture of public submission for visibility and private distribution for resilience is the standard approach for operators running bridges as a service to specific communities.

Install a simple monitoring stack to track bridge uptime and usage. The Tor Metrics portal at metrics.torproject.org/rs shows your relay after it appears in the directory, including bandwidth history, uptime percentage, and flags. For real time monitoring, the Tor control port exposes getinfo queries that monitoring scripts can parse.

Enable the control port in torrc by adding ControlPort 9051 and HashedControlPassword with a hashed value of a strong passphrase. Use nyx, the official Tor relay monitor, to watch live connections, bandwidth, and circuit counts through the control port. Install with apt install nyx and run as the debian-tor user.

Set up external uptime checks from a different machine using a simple curl or netcat probe against the obfs4 port every 5 minutes. If three consecutive checks fail, restart the tor service automatically. Add the restart logic to a systemd timer or a cron job depending on your preference. Document the bridge fingerprint, obfs4 certificate, and contact info in an encrypted note so you can republish if the server needs rebuilding.