Tor-Bridge mit obfs4 auf einem VPS einrichten

Was eine Tor-Bridge ist und warum sie existiert

Eine Tor-Bridge ist ein Zugangspunkt zum Tor-Netzwerk, dessen Adresse nicht in der öffentlichen Relay-Liste veröffentlicht wird. Diese Liste wird als Consensus bezeichnet. Sie ist ein signiertes Dokument, das jeder herunterladen kann, auch ein Zensor. Tor daraus zu blockieren dauert nur einen Nachmittag: Der Zensor lädt den Consensus herunter und blockiert anschließend jede darin enthaltene Adresse am Netzwerkrand. Bridges existieren, weil die veröffentlichte Liste die Schwachstelle ist. Bridge-Adressen werden jeweils nur in kleinen Mengen ausgegeben. Keine einzelne Anfrage liefert dadurch die gesamte Menge.

Eine nicht gelistete Adresse ist nur die halbe Lösung. Deep Packet Inspection (DPI), die Netzwerkverkehr anhand seines Inhalts statt anhand seiner Adresse klassifiziert, erkennt eine Tor-Verbindung an der Form ihres TLS-Handshakes (Transport Layer Security). Ein Zensor kann daher auch ohne Liste erkennen: „Das sieht nach Tor aus“, und die Verbindung blockieren. Ein Pluggable Transport entfernt dieses Signal. Er verpackt den Tor-Datenstrom auf der Client-Seite in ein anderes Protokoll. Ihre Bridge entpackt ihn wieder.

obfs4 ist der Transport, den die meisten Bridges verwenden. Er wandelt den Datenstrom in Bytes ohne Header und ohne festen Handshake um. Dadurch findet DPI kein passendes Muster. Außerdem authentifiziert er den Client. Der Wert cert= in einer Bridge-Zeile ist ein Schlüssel, dessen Besitz der Client nachweisen muss, bevor die Bridge überhaupt antwortet. Das verhindert aktives Prüfen: Verbindet sich ein Zensor mit Ihrer Adresse, um zu testen, ob sie Tor spricht, erhält er keine Antwort und erfährt nichts.

Welchen Pluggable Transport sollten Sie verwenden?

• obfs4 benötigt einen VPS, zwei TCP-Ports und keinen Domainnamen. Das ist die einfachste sinnvolle Variante, die Sie betreiben können, und Gegenstand dieser Anleitung.
• WebTunnel verbirgt die Verbindung innerhalb des normalen HTTPS-Verkehrs zu einer echten Website. Das Tor Project nennt als Voraussetzungen eine statische IPv4-Adresse, eine Domain, die Sie kontrollieren, einen funktionierenden Webserver wie NGINX oder Apache, ein gültiges TLS-Zertifikat sowie mindestens 1 GB RAM; empfohlen werden 4 GB. Das eignet sich für Netzwerke, in denen zufällig wirkender Datenverkehr selbst verdächtig ist, weil ein Land, das kaum mehr als das Aufrufen von Websites erlaubt, HTTPS weiterhin zulässt.
• Snowflake ist eine andere Form der Beteiligung. Freiwillige betreiben kurzlebige WebRTC-Proxys. Dadurch ändern sich die Einstiegspunkte ständig, und es gibt keine stabile Adresse, die ein Zensor blockieren kann. Sie betreiben dafür keinen Bridge. Sie führen einen Proxy aus, der keine feste Adresse benötigt.

Beginnen Sie mit obfs4. Später können Sie auf einer zweiten Adresse eine WebTunnel-Bridge hinzufügen: Wenn beide auf derselben IP-Adresse laufen, legt eine einzige blockierte Adresse beide Dienste lahm.

Was kostet der Betrieb eines Bridges?

[
  {
    "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
  }
]

Seit August 2026 verlangt das Tor Project von einem Bridge mindestens 1 Mbit/s Upstream- und Downstream-Bandbreite. Für ein Guard- oder Middle-Relay sind 10 Mbit/s erforderlich, empfohlen werden 16 Mbit/s. Dabei handelt es sich um veröffentlichte Anforderungen, nicht um Messwerte. Ein neuer Bridge bleibt normalerweise wochenlang deutlich unter seinem eigenen Mindestwert. Auf derselben Anforderungsseite werden für ein Relay mindestens 100 GByte ausgehender Datenverkehr pro Monat verlangt. Das decken bereits die kleinsten Tarife ab. Lesen Sie daher was ein kleiner VPS pro Monat tatsächlich kostet, bevor Sie eine größere Konfiguration planen.

Die Angriffs- und Missbrauchsfläche ist klein. Genau das wird häufig falsch verstanden. Ein Bridge ist der erste Hop. Der Datenverkehr von Ihrem Server wird an ein anderes Tor-Relay weitergeleitet, niemals an eine Website, die ein Benutzer ausgewählt hat. Ihre IP-Adresse erscheint daher nicht als Quelle einer Anfrage in den Web-Logs einer fremden Website. Beschwerdemails, die Betreiber von Exit-Relays bearbeiten müssen, erreichen Sie hier nicht. Prüfen Sie trotzdem die Acceptable-Use-Richtlinie Ihres Anbieters. Einige Hoster behandeln jeden Tor-Dienst als Sonderfall. Ein Bridge und ein Onion Service sind in dieser Hinsicht Spiegelbilder: Ein Bridge ist nur nützlich, weil seine Adresse erreichbar ist und schließlich verteilt wird. Ein v3 Onion Service auf einem vergleichbaren VPS ist dagegen nur so lange nützlich, wie Ihre öffentliche IP-Adresse verborgen bleibt.

Was Sie nicht tun sollten: einen bestehenden öffentlichen Relay unter derselben Adresse in einen Bridge umwandeln. Das Tor Project empfiehlt in diesem Fall, „IP address, name and fingerprint“ zu ändern. Die alte Adresse befindet sich bereits im Consensus, den Zensoren herunterladen. Ein Bridge, der in der vergangenen Woche noch ein öffentliches Relay war, steht damit bereits auf einer Blockliste.

Die Verfügbarkeit ist wichtiger als die Geschwindigkeit. In den Relay-Anforderungen steht: „if your relay is not running for more than 2 hours a day its usefulness is limited“. Für einen Bridge ist das problematischer als für ein Relay, weil jeder Client nur eine Adresse und keine Ausweichmöglichkeit hat. Jeder Neustart trennt alle verbundenen Benutzer. Richten Sie eine TCP-Portprüfung in Uptime Kuma für den obfs4-Port ein. So erfahren Sie an dem Tag, an dem der Port nicht mehr antwortet.

Tor aus dem Tor Project-Repository installieren

Die Distributionspakete sind veraltet. Eine Bridge ist Sicherheitssoftware und sollte aktuell sein. Fügen Sie zuerst das Repository des Projekts hinzu.

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

Schreiben Sie nun die Quelldatei. Die Zeile Suites: muss den Release-Codenamen Ihrer Distribution enthalten. Lesen Sie ihn daher direkt aus dem System aus, statt ihn aus dem Gedächtnis einzugeben.

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

Wenn apt update meldet, dass das Repository keine Release-Datei für Ihren Codenamen enthält, unterstützt das Tor Project diesen Release nicht. Löschen Sie /etc/apt/sources.list.d/tor.sources, führen Sie sudo apt update erneut aus und installieren Sie das Paket tor, das Ihre Distribution bereitstellt. Alles Weitere bleibt unverändert.

Das Paket obfs4proxy stammt direkt aus Debian und Ubuntu (Version 0.0.14 in Debian 13, Stand August 2026). Prüfen Sie, wo die Binärdatei installiert wurde, da ihr Pfad in die Konfiguration eingetragen wird:

command -v obfs4proxy || command -v lyrebird

Das Upstream-Projekt wurde in lyrebird umbenannt. Ein neueres Paket installiert daher möglicherweise stattdessen /usr/bin/lyrebird. Verwenden Sie den Pfad, den dieser Befehl ausgibt.

Konfigurieren Sie die Bridge 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

Jede dieser Zeilen ist mit einem möglichen Fehler verbunden. Prüfen Sie sie daher einzeln.

BridgeRelay 1 weist tor an, seinen Descriptor an die Bridge Authority statt an den öffentlichen Konsens zu senden. Diese einzelne Zeile sorgt dafür, dass das Relay nicht gelistet wird.

ORPort ist der tatsächliche Tor-Port. Er muss aus dem Internet erreichbar sein, weil tor ihn testet und erst dann einen Descriptor veröffentlicht, wenn dieser Test erfolgreich ist.

ServerTransportPlugin gibt tor den auszuführenden Befehl vor. tor startet obfs4proxy als untergeordneten Prozess und kommuniziert über eine Pipe mit ihm. Daher hat obfs4proxy keine eigene Service-Unit und erscheint nie in systemctl status.

ServerTransportListenAddr legt den Port fest, auf dem obfs4proxy lauscht. Wenn Sie diese Zeile weglassen, wählt obfs4proxy beim Start einen freien Port. Nach den meisten Neustarts ist es ein anderer Port. Jede bereits weitergegebene Bridge-Zeile verweist dann auf einen Port, an dem kein Dienst lauscht. Bei diesen Clients wird die Verbindung abgelehnt, und sie versuchen keine weiteren Verbindungen.

ExtORPort auto öffnet den erweiterten ORPort. Dabei handelt es sich um einen Loopback-Kanal, über den obfs4proxy fertige Verbindungen zusammen mit der Adresse des Clients an tor übergibt. Die Einrichtungsanleitung des Tor Project enthält diese Option bei jeder Bridge. Ohne sie kann der Transport diese Adresse nicht an tor melden.

ContactInfo und Nickname sind öffentlich. Verwenden Sie eine Adresse, die Sie lesen, da das Tor Project Sie darüber wegen einer fehlerhaften Bridge kontaktiert. Wählen Sie einen Spitznamen, der Sie nicht identifiziert, wenn Sie lieber unauffällig bleiben möchten.

BridgeDistribution legt fest, welcher Distributor Ihre Adresse an Benutzer weitergibt. Zulässige Werte sind https, email, telegram, settings, none und any. Verwenden Sie für eine erste Bridge any und überlassen Sie die Auswahl dem System. Verwenden Sie none für eine private Bridge, die Sie selbst weitergeben. Dadurch bleibt die Adresse vollständig von der öffentlichen Verteilung ausgeschlossen.

Warum die Portauswahl wichtig ist

Verwenden Sie nicht 9001 für beide Ports. Das Tor Project weist ausdrücklich darauf hin, weil 9001 der traditionelle ORPort ist und Zensoren das Internet nach diesem Port durchsuchen. Die beiden Ports müssen sich außerdem voneinander unterscheiden, weil tor und obfs4proxy jeweils ihren eigenen Listener binden.

Der beste Port für obfs4 ist 443. Ausgehender Datenverkehr über 443 ist in fast jedem eingeschränkten Netzwerk erlaubt, und eine dauerhafte Verbindung dorthin sieht wie eine gewöhnliche Websitzung aus. Das Binden an einen Port unter 1024 erfordert einen zusätzlichen Schritt, weil obfs4proxy nicht als root ausgeführt wird:

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

Fügen Sie diese beiden Zeilen in jedem Editor ein, der geöffnet wird:

[Service]
NoNewPrivileges=no

Die Capability allein reicht nicht aus. Die systemd-Einstellung NoNewPrivileges verhindert, dass ein Prozess Privilegien erlangt, über die sein übergeordneter Prozess nicht verfügte. Eine Datei-Capability ist genau das. Deshalb kann obfs4proxy nicht an 443 binden, solange diese Einstellung aktiviert ist.

Wenn Sie diesen Schritt überspringen möchten, wählen Sie einen unauffälligen hohen Port und notieren Sie ihn. Unabhängig von Ihrer Wahl dürfen Sie den obfs4-Port später nicht ändern. Eine Bridge-Zeile bindet Adresse, Port, Fingerabdruck und Zertifikat zusammen. Daher funktioniert jede Kopie, die bereits im Browser eines Benutzers gespeichert ist, nicht mehr, sobald der Port geändert wird.

Öffnen Sie die Ports in beiden Firewalls

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

Beide Ports müssen geöffnet sein. Bei den meisten Providern läuft zusätzlich eine zweite Firewall im Control Panel, von der ufw nichts weiß. Eine Regel, die auf dem Server vorhanden ist, aber nicht im Panel, erzeugt eine Bridge, die nie erreichbar ist und nie einen Descriptor veröffentlicht. Falls eine der beiden Firewalls für Sie neu ist, erklären die ufw-Regeln, die ein frischer VPS benötigt, und was ein geöffneter Port unter Linux tatsächlich ist die Grundlagen. Sichern Sie außerdem SSH mit Schlüsseln und einer gehärteten sshd-Konfiguration ab. Eine nicht gelistete Bridge auf einem Server mit passwortbasiertem SSH bleibt ein Server mit passwortbasiertem SSH.

Starten Sie den Dienst und lesen Sie anschließend das Log

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

Debian und Ubuntu liefern zwei Units aus. tor.service ist ein kleiner Wrapper, während tor@default.service der Prozess ist, der die eigentliche Arbeit ausführt. Deshalb wirkt journalctl -u tor fast leer, während sich das gesuchte Log unter tor@default befindet.

Zwei Zeilen zeigen, dass der Start erfolgreich war:

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

Die erste Zeile bedeutet, dass der Erreichbarkeitstest erfolgreich war und der Descriptor an die Bridge-Autorität übermittelt wurde. Wenn sie nie erscheint, verwirft etwas zwischen dem Internet und Ihrem Server den Datenverkehr zum ORPort. Die zweite Zeile muss den von Ihnen konfigurierten Port anzeigen. Ein anderer Port bedeutet, dass Tor ServerTransportListenAddr nie angewendet hat. Die häufigste Ursache ist ein nicht übereinstimmender Transportname: In beiden Direktiven muss obfs4 stehen.

Bestätigen Sie, dass beide Listener vorhanden sind:

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

Wo ist meine Bridge-Zeile?

obfs4proxy schreibt eine Vorlage in das Datenverzeichnis von tor:

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

Dieses Verzeichnis gehört dem Benutzer tor und hat den Modus 700. Ohne sudo erhalten Sie daher Permission denied. Die Datei enthält eine Zeile in dieser Form:

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

Ersetzen Sie <IP ADDRESS> durch die öffentliche Adresse Ihres Servers, <PORT> durch den obfs4-Port und nicht durch den ORPort und <FINGERPRINT> durch den Identitäts-Fingerprint, den tor in sein Datenverzeichnis geschrieben hat:

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

Die erste Datei enthält Ihren Nickname und den Identitäts-Fingerprint, der in eine Bridge-Zeile gehört. Die zweite enthält den gehashten Fingerprint. Diesen fügen Sie in Relay Search ein, um zu prüfen, ob Ihre Bridge läuft und ungefähr wie viele Clients sie erreichen. Die beiden Werte sind nicht austauschbar. Eine Bridge-Zeile mit dem gehashten Wert passt nicht zum Identitätsschlüssel, den Ihre Bridge präsentiert. Der Client weist die gerade aufgebaute Verbindung deshalb zurück.

Wie erreicht eine Bridge tatsächlich Benutzer?

Sie geben Ihre Bridge-Zeile nicht an beliebige Personen weiter. Sobald der Deskriptor die Bridge Authority erreicht, weist das Verteilungssystem (rdsys, der Nachfolger von BridgeDB) Ihre Bridge einem Distributor zu. Benutzer fragen diesen Distributor nach Bridges. Im August 2026 gibt es folgende Wege:

• Das Webformular unter bridges.torproject.org/options, das Bridge-Zeilen nach einer Captcha-Prüfung ausgibt.
• Eine E-Mail an bridges@torproject.org von einer Gmail- oder Riseup-Adresse. Daraufhin werden Bridge-Zeilen zurückgesendet. Diese Einschränkung beim Anbieter besteht, weil unbegrenzt viele kostenlose Konten es einer zensierenden Stelle ermöglichen würden, jede Bridge zu ermitteln.
• Der Telegram-Bot @GetBridgesBot. Senden Sie /start und anschließend /obfs4 oder /webtunnel.
• Tor Browser selbst unter „Settings“ und anschließend „Connection“. Dort ruft „Request bridges“ die Bridges über den moat-Kanal ab.

Eine neue Bridge erscheint etwa drei Stunden nach der Einrichtung in Relay Search. Bei Benutzern dauert es deutlich länger. Die Formulierung des Tor Project lautet: „Es kann mehrere Tage oder Wochen dauern, bis Sie eine konsistente Gruppe von Benutzern sehen.“ Eine geringe Nutzung während der ersten zwei Wochen ist normal und kein Fehler.

Mit BridgeDistribution none deaktivieren Sie all diese Wege. Die Bridge-Zeile können Sie dann selbst an die Personen senden, die sie benötigen, und zwar über einen Kanal, den die zensierende Stelle nicht mitliest.

Wenn etwas nicht funktioniert

Keine Selbsttest-Zeile im Log. Der ORPort ist nicht erreichbar. Testen Sie ihn von einem anderen Rechner mit nc -vz your.ip 8443. Wenn der Befehl hängt, werden Pakete verworfen. Prüfen Sie daher ufw und das Panel des Providers. Eine Ablehnung bedeutet, dass tor nicht lauscht. Prüfen Sie dann ss -lntp und suchen Sie im Log nach einem Konfigurationsfehler.

Der registrierte Transport zeigt einen Port, den Sie nicht ausgewählt haben. tor hat ServerTransportListenAddr ignoriert. Der Transportname muss exakt mit dem Namen in ServerTransportPlugin übereinstimmen, und beide müssen obfs4 sein.

obfs4proxy kann nicht an Port 443 gebunden werden. Prüfen Sie die Berechtigung mit getcap /usr/bin/obfs4proxy. Prüfen Sie anschließend mit systemctl show tor@default -p NoNewPrivileges, ob die Überschreibung die Unit erreicht hat. Wenn dabei NoNewPrivileges=yes ausgegeben wird, wurde Ihr Drop-in auf eine Unit angewendet, die nicht ausgeführt wird.

Nichts innerhalb von /var/lib/tor/pt_state/. tor hat den Transport nicht gestartet. Der Pfad in ServerTransportPlugin ist daher falsch. Vergleichen Sie ihn mit der Ausgabe von command -v obfs4proxy.

Clients stellen nach einer Änderung keine Verbindung mehr her. Jede Änderung an der Adresse oder am obfs4-Port macht alle bereits verteilten Bridge-Zeilen ungültig. Prüfen Sie außerdem, ob sich die öffentliche IP-Adresse des Servers geändert hat. Das kann bei einem Rebuild bei einigen Providern passieren.

tor startet überhaupt nicht. Führen Sie sudo -u debian-tor tor --verify-config -f /etc/tor/torrc aus. Der Befehl analysiert die Datei, gibt die beanstandete Zeile aus und lässt den laufenden Dienst unverändert.

FAQ

Wird mein VPS-Anbieter wegen einer Tor-Bridge Beschwerde einlegen?

Eine Bridge ist ein Einstiegspunkt. Der Datenverkehr, der Ihren Server verlässt, geht daher zu anderen Tor-Relays und niemals zu einer vom Benutzer ausgewählten Website. Ihre IP-Adresse erscheint in keinem Web-Log als Quelle einer Anfrage. Genau das führt zu den Beschwerden, mit denen Betreiber von Exit-Relays konfrontiert sind. Die Hosting-Regeln unterscheiden sich jedoch weiterhin. Einige Anbieter behandeln jeden Tor-Dienst als Sonderfall. Lesen Sie daher vor dem Start die Richtlinie zur zulässigen Nutzung und tragen Sie eine dort genannte Adresse in ContactInfo ein.

Wie viel Bandbreite verwendet eine Tor-Bridge?

Das veröffentlichte Minimum beträgt 1 Mbit/s im Upstream und Downstream. Für ein Guard- oder Middle-Relay sind es 10 Mbit/s. Die tatsächliche Nutzung beginnt nahe null, da Ihre Bridge nur Datenverkehr für die Benutzer überträgt, die ein Distributor an sie weiterleitet. Wenn Sie eine feste Obergrenze benötigen, setzen Sie RelayBandwidthRate und RelayBandwidthBurst in torrc.

Warum hat noch niemand eine Verbindung zu meiner neuen Bridge hergestellt?

Eine Bridge benötigt etwa drei Stunden, um in Relay Search zu erscheinen. Nach Einschätzung des Tor Project dauert es mehrere Tage oder Wochen, bis sich ein konstanter Benutzerkreis bildet. Prüfen Sie, ob der Descriptor veröffentlicht wurde. Das ist die Zeile zur Selbstprüfung in journalctl -u tor@default. Suchen Sie Ihren gehashten Fingerprint in Relay Search und bestätigen Sie, dass BridgeDistribution nicht auf none gesetzt ist.

Sollte ich obfs4 oder WebTunnel ausführen?

Führen Sie obfs4 aus, wenn dies Ihre erste Bridge ist: ein VPS, zwei Ports, keine Domain und kein Zertifikat. Verwenden Sie WebTunnel, wenn Datenverkehr mit zufällig wirkendem Inhalt selbst blockiert wird. Dafür benötigen Sie eine Domain, die Sie kontrollieren, einen echten Webserver, ein gültiges TLS-Zertifikat und mindestens 1 GB RAM. Verwenden Sie separate Adressen, wenn Sie beide ausführen. Andernfalls würde eine gesperrte IP-Adresse zwei Bridges gleichzeitig unbrauchbar machen.

Was passiert, wenn ich den obfs4-Port später ändere?

Jede bereits verteilte Bridge-Zeile funktioniert nicht mehr. Eine Bridge-Zeile bindet Adresse, Port, Fingerprint und Zertifikat aneinander. Ein Client mit der alten Zeile stellt daher eine Verbindung zu einem Port her, an dem kein Dienst lauscht, und bricht ab. Das Gleiche gilt, wenn sich die öffentliche IP-Adresse des Servers ändert. Wählen Sie den Port während der Einrichtung und ändern Sie ihn anschließend nicht mehr.