SSD Nodes Learn Hosting plans →
Gidsen Matt ConnorDoor Matt Connor · Bijgewerkt 2026-08-28

Tor bridge met obfs4 draaien op een VPS

Leer hoe u een obfs4 Tor bridge opzet op een VPS. Wij behandelen de juiste torrc configuratie, poortselectie, firewall instellingen en hoe u in de logs ziet dat het werkt.

Wat een Tor bridge is en waarom deze bestaat

Een Tor bridge is een toegangspunt tot het Tor-netwerk waarvan het adres niet in de openbare relay-lijst staat. Die lijst, de consensus genoemd, is een ondertekend document dat iedereen kan downloaden, inclusief een censor. Het blokkeren van Tor op basis van deze lijst is eenvoudig: haal de consensus op en blokkeer vervolgens elk adres in de lijst bij de netwerkgrens. Bridges bestaan omdat de gepubliceerde lijst het zwakke punt is. Bridge-adressen worden in kleine aantallen verstrekt, zodat een enkel verzoek nooit de volledige set prijsgeeft.

Een niet-vermeld adres is slechts de helft van de oplossing. Deep packet inspection (DPI), dat verkeer classificeert op basis van de inhoud in plaats van het adres, herkent een Tor-verbinding aan de vorm van de TLS (transport layer security) handshake. Een censor zonder lijst kan nog steeds zien dat verkeer "op Tor lijkt" en de verbinding verbreken. Een pluggable transport verwijdert dat signaal. Het verpakt de Tor-stroom aan de clientzijde in een ander protocol, waarna uw bridge het weer uitpakt.

obfs4 is het transport dat op de meeste bridges draait. Het zet de stroom om in bytes zonder header en zonder vaste handshake, waardoor DPI geen patroon kan herkennen. Het authenticeert bovendien de client. De cert=-waarde in een bridge-regel is een sleutel waarvan de client moet aantonen dat deze in bezit is voordat de bridge überhaupt antwoordt. Dit voorkomt actieve probing: een censor die verbinding maakt met uw adres om te testen of het Tor spreekt, krijgt geen antwoord en komt niets te weten.

Welk pluggable transport moet u draaien?

  • obfs4 vereist één VPS, twee TCP-poorten en geen domeinnaam. Dit is de eenvoudigste nuttige optie die u kunt draaien en het onderwerp van deze handleiding.
  • WebTunnel verbergt de verbinding in regulier HTTPS-verkeer naar een echte website. Het Tor Project stelt de volgende vereisten: een statisch IPv4-adres, een domein dat u beheert, een werkende webserver zoals NGINX of Apache, een geldig TLS-certificaat en ten minste 1 GB RAM (4 GB aanbevolen). Dit is geschikt voor netwerken waar willekeurig ogend verkeer op zichzelf al verdacht is, omdat een land dat weinig anders toestaat dan browsen, HTTPS meestal wel toelaat.
  • Snowflake is een andere vorm van bijdragen. Vrijwilligers draaien kortstondige WebRTC-proxies, waardoor de toegangspunten constant veranderen en er geen stabiel adres is dat een censor kan blokkeren. U beheert hiervoor geen bridge. U draait een proxy en deze heeft geen vast adres nodig.

Begin met obfs4. U kunt later een WebTunnel-bridge toevoegen op een tweede adres: als u beide op één IP-adres draait, zorgt het blokkeren van dat ene adres ervoor dat beide onbereikbaar zijn.

Wat kost het draaien van een bridge?

ChartTor Project published minimum bandwidth, August 2026
The data behind this chart
[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

Sinds augustus 2026 vraagt het Tor Project voor een bridge om ten minste 1 Mbit/s aan upstream- en downstream-bandbreedte. Voor een guard- of middle-relay wordt 10 Mbit/s gevraagd, waarbij 16 Mbit/s wordt aanbevolen. Dit zijn gepubliceerde vereisten, geen metingen. Een nieuwe bridge zit doorgaans wekenlang ver onder het eigen minimum. Dezelfde pagina met vereisten vraagt voor een relay om ten minste 100 GByte aan uitgaand verkeer per maand; de kleinste abonnementen dekken dit al. Lees daarom wat een kleine VPS per maand kost voordat u iets groters kiest.

Het risico op misbruik is klein, en dit is het punt waar mensen zich vaak in vergissen. Een bridge is de eerste hop. Verkeer dat uw server verlaat, gaat naar een andere Tor-relay, nooit naar een website die een gebruiker heeft gekozen. Uw IP-adres verschijnt nooit in het weblog van een vreemde als bron van een verzoek, waardoor de klachtenmails die exit-relay-operators ontvangen hier niet aankomen. Controleer desondanks het acceptabel-gebruikbeleid van uw provider, omdat sommige hosts elke Tor-dienst als een bijzonder geval behandelen. Een bridge en een onion-service zijn in dit opzicht elkaars spiegelbeeld: een bridge is alleen nuttig omdat het adres bereikbaar is en uiteindelijk wordt uitgedeeld, terwijl een v3 onion-service op hetzelfde type VPS alleen nuttig is zolang uw publieke IP-adres verborgen blijft.

Eén ding moet u niet doen: een bestaande publieke relay omzetten naar een bridge op hetzelfde adres. Het advies van het Tor Project voor dat scenario is om het "IP-adres, de naam en de fingerprint" te wijzigen, omdat het oude adres al in de consensus staat die censors downloaden. Een bridge die vorige week nog een publieke relay was, staat al op een blokkeerlijst.

Uptime is belangrijker dan snelheid. De relay-vereisten stellen dat "als uw relay meer dan 2 uur per dag niet draait, de bruikbaarheid beperkt is". Voor een bridge is dit nog kritieker, omdat elke client slechts één adres heeft zonder fallback. Een herstart verbreekt de verbinding met alle gebruikers. Configureer een TCP-poortcontrole in Uptime Kuma op de obfs4-poort, zodat u op de dag dat deze niet meer reageert op de hoogte wordt gesteld.

Tor installeren vanuit de repository van het Tor Project

Distributiepakketten lopen achter op schema, en een bridge is beveiligingssoftware die up-to-date moet zijn. Voeg eerst de repository van het project zelf toe.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget lsb-release
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

Schrijf nu het bronbestand. De regel Suites: moet uw release-codename bevatten, dus lees deze uit het systeem in plaats van deze uit het hoofd te typen.

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring obfs4proxy

Als apt update meldt dat de repository geen Release-bestand heeft voor uw codename, dan ondersteunt het Tor Project die release niet. Verwijder /etc/apt/sources.list.d/tor.sources, voer sudo apt update opnieuw uit en installeer het tor-pakket dat uw distributie aanbiedt. Alles hieronder is identiek.

Het obfs4proxy-pakket is afkomstig van Debian en Ubuntu zelf (versie 0.0.14 in Debian 13, per augustus 2026). Controleer waar het binaire bestand is geplaatst, omdat het pad in de configuratie moet worden opgenomen:

command -v obfs4proxy || command -v lyrebird

De upstream-ontwikkelaars hebben het project hernoemd naar lyrebird, dus een nieuwer pakket installeert mogelijk /usr/bin/lyrebird in plaats daarvan. Gebruik het pad dat door dat commando wordt getoond.

De bridge configureren in /etc/tor/torrc

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

Elk van deze regels kan leiden tot een fout, dus behandel ze één voor één.

BridgeRelay 1 instrueert tor om de descriptor naar de bridge authority te sturen in plaats van naar de publieke consensus. Deze enkele regel zorgt ervoor dat de relay niet in de lijst verschijnt.

ORPort is de werkelijke Tor-poort. Deze moet bereikbaar zijn vanaf het internet, omdat tor de poort test en weigert een descriptor te publiceren totdat die test slaagt.

ServerTransportPlugin geeft tor de opdracht om uit te voeren. tor start obfs4proxy als een onderliggend proces en communiceert via een pipe; obfs4proxy heeft daarom geen eigen service-unit en verschijnt nooit in systemctl status.

ServerTransportListenAddr legt de poort vast waarop obfs4proxy luistert. Laat u deze regel weg, dan kiest obfs4proxy bij het opstarten een vrije poort, en na de meeste herstarts een andere. Elke bridge-regel die u al heeft verstrekt, wijst dan naar een poort waar niets luistert. Die clients krijgen een geweigerde verbinding en stoppen met proberen.

ExtORPort auto opent de extended ORPort, een loopback-kanaal dat obfs4proxy gebruikt om voltooide verbindingen samen met het adres van de client terug te sturen naar tor. De installatiehandleiding van het Tor Project bevat deze regel voor elke bridge, omdat het transport zonder deze poort het adres niet aan tor kan rapporteren.

ContactInfo en Nickname zijn beide publiek. Gebruik een adres dat u daadwerkelijk leest, aangezien het Tor Project u via dit adres bereikt als een bridge defect is. Kies een bijnaam die u niet identificeert als u liever anoniem blijft.

BridgeDistribution kiest welke distributeur uw adres aan gebruikers verstrekt. De geaccepteerde waarden zijn https, email, telegram, settings, none en any. Gebruik any voor een eerste bridge en laat het systeem beslissen. Gebruik none voor een private bridge die u zelf verspreidt; hiermee blijft het adres volledig buiten de publieke distributie.

Waarom de keuze van de poort belangrijk is

Gebruik niet 9001 voor beide poorten. Het Tor Project adviseert dit expliciet, omdat 9001 de traditionele ORPort is en censuurfilters het internet hierop scannen. De twee poorten moeten ook van elkaar verschillen, aangezien tor en obfs4proxy elk hun eigen listener binden.

De meest effectieve poort voor obfs4 is 443. Uitgaand verkeer op poort 443 is op vrijwel elk beperkt netwerk toegestaan, en een langdurige verbinding hiermee lijkt op een normale websessie. Voor het binden van een poort onder 1024 is een extra stap vereist, omdat obfs4proxy niet als root draait:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

Voeg deze twee regels toe in elke editor die opent:

[Service]
NoNewPrivileges=no

De capability alleen is niet voldoende. De instelling NoNewPrivileges van systemd voorkomt dat een proces privileges verkrijgt die de ouder niet had, en een file capability is precies dat; hierdoor kan obfs4proxy poort 443 niet binden zolang deze instelling actief is.

Als u deze stap liever overslaat, kies dan een onopvallende hoge poort en noteer deze. Wat u ook kiest, wijzig de obfs4-poort daarna niet meer. Een bridge-regel koppelt het adres, de poort, de fingerprint en het certificaat aan elkaar. Elke kopie die al in de browser van een gebruiker staat, werkt niet meer zodra de poort wordt veranderd.

Open de poorten op beide firewalls

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

Beide poorten moeten openstaan. De meeste providers hanteren een tweede firewall in hun configuratiescherm waar ufw geen weet van heeft. Een regel die wel op de server zelf bestaat, maar niet in het configuratiescherm, resulteert in een verbinding die onbereikbaar blijft en geen descriptor publiceert. Als een van deze onderwerpen nieuw voor u is, bieden de ufw-regels die een nieuwe VPS nodig heeft en wat een listening port op Linux daadwerkelijk is uitkomst. Nu u toch bezig bent, beveilig SSH met sleutels en een geharde sshd-configuratie. Een niet-geconfigureerde verbinding op een server met SSH-wachtwoordauthenticatie blijft een server met SSH-wachtwoordauthenticatie.

Start de service en lees het logbestand

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian en Ubuntu leveren twee units mee. tor.service is een kleine wrapper en tor@default.service is het proces dat het werk uitvoert; daarom lijkt journalctl -u tor vrijwel leeg, terwijl het logbestand dat u nodig heeft onder tor@default staat.

Twee regels bevestigen dat het werkt:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

De eerste regel betekent dat de bereikbaarheidstest is geslaagd en de descriptor naar de bridge authority is verzonden. Als deze regel niet verschijnt, blokkeert iets tussen het internet en uw server het verkeer naar de ORPort. De tweede regel moet de poort tonen die u heeft geconfigureerd. Een afwijkende poort daar betekent dat tor de instelling ServerTransportListenAddr niet heeft toegepast; de gebruikelijke oorzaak is een niet-overeenkomende transportnaam: deze moet op beide richtlijnen als obfs4 staan vermeld.

Controleer of de twee listeners actief zijn:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

Waar vind ik mijn bridge-regel?

obfs4proxy schrijft een sjabloon naar de datamap van tor:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

Die map is eigendom van de gebruiker tor en heeft modus 700, dus zonder sudo krijgt u Permission denied. Het bestand bevat een regel in deze vorm:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Vervang <IP ADDRESS> door het publieke adres van uw server, <PORT> door de obfs4-poort (niet de ORPort) en <FINGERPRINT> door de identity fingerprint die tor in zijn datamap heeft geschreven:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

Het eerste bestand bevat uw bijnaam en de identity fingerprint die in een bridge-regel thuishoort. Het tweede bevat de gehashte fingerprint; dit is wat u plakt in Relay Search om te zien of uw bridge draait en hoeveel clients deze ongeveer bereiken. De twee zijn niet uitwisselbaar. Een bridge-regel met de gehashte waarde komt niet overeen met de identity key die uw bridge presenteert, waardoor de client de zojuist geopende verbinding afwijst.

Hoe bereikt een bridge daadwerkelijk gebruikers?

U deelt uw bridge-line niet zelf uit. Zodra de descriptor de bridge authority bereikt, wijst het distributiesysteem (rdsys, de opvolger van BridgeDB) uw bridge toe aan een distributeur. Gebruikers vragen vervolgens bij die distributeur om bridges. Sinds augustus 2026 zijn dit de routes:

  • Het webformulier op bridges.torproject.org/options, dat na een captcha bridge-lines verstrekt.
  • E-mail naar bridges@torproject.org vanaf een Gmail- of Riseup-adres; u ontvangt dan bridge-lines als antwoord. De beperking op e-mailproviders bestaat omdat onbeperkte gratis accounts een censor in staat zouden stellen elke bridge te inventariseren.
  • De Telegram-bot @GetBridgesBot. Stuur /start, gevolgd door /obfs4 of /webtunnel.
  • Tor Browser zelf, onder Instellingen en vervolgens Verbinding, waar "Request bridges" ze ophaalt via het moat-kanaal.

Een nieuwe bridge verschijnt ongeveer drie uur na de configuratie in Relay Search. Bij gebruikers duurt dit aanzienlijk langer: volgens de bewoordingen van het Tor Project "kan het enkele dagen tot weken duren voordat u een consistente groep gebruikers ziet." Een rustige eerste twee weken is normaal en duidt niet op een fout.

Door BridgeDistribution none in te stellen, kiest u ervoor om van al deze distributiemethoden af te zien. De bridge-line is dan volledig in uw beheer om te delen met de mensen die deze nodig hebben, via een kanaal dat niet door de censor wordt gemonitord.

Wanneer iets niet werkt

Geen zelftest-regel in het logbestand. De ORPort is niet bereikbaar. Test dit vanaf een andere machine met nc -vz your.ip 8443. Een hangend proces betekent dat pakketten worden tegengehouden; controleer daarom ufw en het configuratiepaneel van uw provider. Een weigering betekent dat tor niet luistert; controleer ss -lntp en lees het logbestand op configuratiefouten.

De geregistreerde transport toont een poort die u niet heeft gekozen. tor heeft ServerTransportListenAddr genegeerd. De naam van de transport moet exact overeenkomen met die in ServerTransportPlugin, en beide moeten obfs4 zijn.

obfs4proxy wil niet binden aan poort 443. Bevestig de mogelijkheid met getcap /usr/bin/obfs4proxy en controleer daarna of de override de unit heeft bereikt met systemctl show tor@default -p NoNewPrivileges. Als dit NoNewPrivileges=yes weergeeft, is uw drop-in toegepast op een unit die niet actief is.

Niets in /var/lib/tor/pt_state/. tor heeft de transport nooit gestart, wat betekent dat het pad in ServerTransportPlugin onjuist is. Vergelijk dit met de uitvoer van command -v obfs4proxy.

Clients maken geen verbinding meer na een wijziging. Elke wijziging aan het adres of de obfs4-poort maakt elke reeds verspreide bridge-regel ongeldig. Controleer of het publieke IP-adres van de server ook is gewijzigd; dit gebeurt bij sommige providers na een rebuild.

tor start helemaal niet. Voer sudo -u debian-tor tor --verify-config -f /etc/tor/torrc uit. Dit commando parseert het bestand, toont de regel waar bezwaar tegen wordt gemaakt en laat de draaiende service ongemoeid.

FAQ

Zal mijn VPS-provider klagen over een Tor-bridge?

Een bridge is een toegangspunt, dus verkeer dat uw server verlaat, gaat naar andere Tor-relays en nooit naar een site die een gebruiker heeft gekozen. Uw IP-adres verschijnt in geen enkel weblogboek als de bron van een verzoek, en dat is precies wat de klachten veroorzaakt waar exit-relay-operators mee te maken krijgen. Hostingregels variëren echter en sommige providers behandelen elke Tor-dienst als een bijzonder geval. Lees daarom het acceptabel-gebruikbeleid voordat u begint en voer een adres in dat u leest in ContactInfo.

Hoeveel bandbreedte verbruikt een Tor-bridge?

Het gepubliceerde minimum is 1 Mbit/s up- en download, tegenover 10 Mbit/s voor een guard- of middle-relay. Het werkelijke gebruik begint bij bijna nul, omdat uw bridge alleen verkeer verwerkt voor de gebruikers die een distributeur ernaartoe stuurt. Als u een harde limiet wilt instellen, configureer dan RelayBandwidthRate en RelayBandwidthBurst in torrc.

Waarom heeft niemand verbinding gemaakt met mijn nieuwe bridge?

Het duurt ongeveer drie uur voordat een bridge verschijnt in Relay Search, en de richtlijn van het Tor Project is dat het opbouwen van een consistente groep gebruikers enkele dagen tot weken duurt. Controleer of de descriptor is gepubliceerd (dit is de zelf-testregel in journalctl -u tor@default), zoek uw gehashte fingerprint op in Relay Search en bevestig dat BridgeDistribution niet is ingesteld op none.

Moet ik obfs4 of WebTunnel draaien?

Draai obfs4 als dit uw eerste bridge is: één VPS, twee poorten, geen domein, geen certificaat. Draai WebTunnel waar willekeurig ogend verkeer zelf wordt geblokkeerd, aangezien dit een domein vereist dat u beheert, een echte webserver, een geldig TLS-certificaat en ten minste 1 GB RAM. Plaats ze op afzonderlijke adressen als u beide draait, omdat één geblokkeerd IP-adres anders twee bridges tegelijk onbruikbaar zou maken.

Wat gebeurt er als ik de obfs4-poort later wijzig?

Elke reeds gedistribueerde bridge-regel stopt met werken. Een bridge-regel koppelt het adres, de poort, de fingerprint en het certificaat aan elkaar. Een client die de oude regel bezit, opent een verbinding naar een poort waar niets luistert en geeft het op. Hetzelfde geldt wanneer het publieke IP-adres van de server verandert. Kies de poort tijdens de installatie en wijzig deze daarna niet meer.