Tor-Bridge mit obfs4 auf einem VPS einrichten

Was eine Tor-Bridge ist und warum sie existiert

Eine Tor-Bridge ist ein Einstiegspunkt in das 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 kann sie herunterladen. Tor daraus zu blockieren dauert nur einen Nachmittag: Den Consensus abrufen und anschließend jede darin enthaltene Adresse an der Netzgrenze blockieren. Bridges existieren, weil die veröffentlichte Liste die Schwachstelle ist. Bridge-Adressen werden jeweils nur in kleinen Mengen herausgegeben. Dadurch liefert keine einzelne Anfrage die vollständige Menge.

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

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 Muster, nach dem es suchen kann. Außerdem authentifiziert obfs4 den Client. Der Wert cert= innerhalb einer Bridge-Zeile ist ein Schlüssel, dessen Besitz der Client nachweisen muss, bevor die Bridge überhaupt antwortet. Dadurch werden aktive Sondierungen verhindert: Ein Zensor, der eine Verbindung zu Ihrer Adresse herstellt, um zu prüfen, ob dort Tor spricht, erhält keine Antwort und erfährt nichts.

Welchen Pluggable Transport sollten Sie einsetzen?

• obfs4 benötigt einen VPS, zwei TCP-Ports und keinen Domainnamen. Es ist die einfachste sinnvolle Option, die Sie selbst betreiben können, und Gegenstand dieser Anleitung.
• WebTunnel verbirgt die Verbindung in gewöhnlichem HTTPS-Verkehr zu einer echten Website. Das Tor Project nennt dafür eine statische IPv4-Adresse, eine Domain unter Ihrer Kontrolle, einen funktionierenden Webserver wie NGINX oder Apache, ein gültiges TLS-Zertifikat sowie mindestens 1 GB RAM; empfohlen werden 4 GB. WebTunnel eignet sich für Netzwerke, in denen zufällig wirkender Datenverkehr selbst verdächtig ist. Ein Land, das kaum mehr als Webzugriff zulässt, erlaubt HTTPS in der Regel weiterhin.
• Snowflake ist eine andere Form der Unterstützung. Freiwillige betreiben kurzlebige WebRTC-Proxys. Dadurch ändern sich die Einstiegspunkte ständig, und für Zensoren gibt es keine stabile Adresse zum Blockieren. Sie betreiben dafür keinen Bridge. Sie betreiben einen Proxy, 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 Sie beide auf einer IP-Adresse betreiben, führt das Blockieren einer einzelnen Adresse zum Ausfall beider.

Welche Kosten entstehen beim Betrieb einer Bridge?

[
  {
    "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 einer Bridge mindestens 1 Mbit/s Upstream- und Downstream-Bandbreite. Für einen Guard- oder Middle-Relay werden 10 Mbit/s verlangt, empfohlen werden 16 Mbit/s. Dabei handelt es sich um veröffentlichte Anforderungen, nicht um Messwerte. Eine neue Bridge bleibt in der Regel wochenlang deutlich unter ihrem eigenen Mindestwert. Auf derselben Anforderungsseite werden für einen Relay mindestens 100 GByte ausgehender Traffic pro Monat verlangt. Das decken bereits die kleinsten Tarife ab. Lesen Sie daher was ein kleiner VPS tatsächlich pro Monat kostet, bevor Sie etwas Größeres einrichten.

Die Angriffsfläche für Missbrauch ist klein. Genau das wird häufig falsch verstanden. Eine Bridge ist der erste Hop. Der Traffic, der Ihren Server verlässt, geht an einen anderen Tor-Relay und niemals an eine Website, die ein Benutzer ausgewählt hat. Ihre IP-Adresse erscheint in keinem Weblog eines Fremden als Quelle einer Anfrage. Die Beschwerdemails, die Exit-Relay-Betreiber bearbeiten, erreichen Sie daher nicht. Prüfen Sie trotzdem die Richtlinien zur akzeptablen Nutzung Ihres Providers. Manche Hoster behandeln jeden Tor-Dienst als Sonderfall.

Vermeiden Sie Folgendes: Wandeln Sie keinen bestehenden öffentlichen Relay unter derselben Adresse in eine Bridge um. Das Tor Project empfiehlt in diesem Fall, die „IP address, name and fingerprint“ zu ändern, weil die alte Adresse bereits im Consensus enthalten ist, den Zensoren herunterladen. Eine Bridge, die in der vergangenen Woche noch ein öffentlicher Relay war, steht bereits auf einer Blocklist.

Die Verfügbarkeit ist wichtiger als die Geschwindigkeit. In den Relay-Anforderungen heißt es: „if your relay is not running for more than 2 hours a day its usefulness is limited“. Für eine Bridge ist das problematischer als für einen Relay, weil jeder Client nur eine Adresse und keinen Fallback hat. Ein Neustart trennt alle Benutzer, die sie verwenden. Richten Sie eine TCP-Portprüfung in Uptime Kuma für den obfs4-Port ein. So erfahren Sie an dem Tag, an dem er nicht mehr antwortet, von der Unterbrechung.

Tor aus dem Repository des Tor Project installieren

Die Distributionspakete sind oft veraltet. Ein Bridge-Dienst ist jedoch Sicherheitssoftware und sollte aktuell sein. Fügen Sie zuerst das eigene 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 jetzt die Quelldatei. Die Zeile Suites: muss den Release-Codenamen Ihres Systems 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 tor-Paket, 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. Daher kann ein neueres Paket stattdessen /usr/bin/lyrebird installieren. Verwenden Sie den Pfad, den dieser Befehl ausgibt.

Bridge in /etc/tor/torrc konfigurieren

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 eigenen Fehlerbild verbunden. Gehen Sie sie deshalb einzeln durch.

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

ORPort ist der eigentliche Tor-Port. Er muss aus dem Internet erreichbar sein, weil tor ihn testet und die Veröffentlichung eines Deskriptors verweigert, bis 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. Deshalb 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. Dadurch verweist jede bereits ausgegebene Bridge-Zeile auf einen Port, an dem kein Prozess lauscht. Bei diesen Clients wird die Verbindung abgelehnt, und sie versuchen es nicht erneut.

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 zurückgibt. Der Einrichtungsleitfaden 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 beide öffentlich. Verwenden Sie eine Adresse, unter der Sie erreichbar sind, weil das Tor Project Sie darüber über eine nicht funktionierende 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 any für eine erste Bridge 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 Wahl des Ports wichtig ist

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

Der beste Port für obfs4 ist 443. Ausgehender Verkehr über 443 ist in nahezu jedem eingeschränkten Netzwerk möglich, und eine dauerhaft bestehende 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 hinzu, der geöffnet wird:

[Service]
NoNewPrivileges=no

Die Capability allein reicht nicht aus. systemd's NoNewPrivileges verhindert, dass ein Prozess Privilegien erhält, über die sein Elternprozess nicht verfügte. Eine Datei-Capability ist genau das. Daher kann obfs4proxy 443 nicht 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 funktionieren Kopien, die bereits im Browser eines Benutzers gespeichert sind, nicht mehr, sobald sich der Port ändert.

Ports in beiden Firewalls öffnen

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

Beide Ports müssen geöffnet sein. Die meisten Anbieter betreiben zusätzlich eine zweite Firewall in ihrem Control Panel, die ufw nicht kennt. Eine Regel, die auf dem Server, aber nicht im Panel vorhanden ist, erzeugt eine Bridge, die nie erreichbar ist und keinen Descriptor veröffentlicht. Wenn eine der beiden Seiten 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 währenddessen SSH mit Schlüsseln und einer gehärteten sshd-Konfiguration ab. Eine nicht gelistete Bridge auf einem Server mit passwortbasierter SSH-Authentifizierung bleibt ein Server mit passwortbasierter SSH-Authentifizierung.

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, und tor@default.service ist der Prozess, der die eigentliche Arbeit übernimmt. Deshalb wirkt journalctl -u tor nahezu 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-Authority übermittelt wurde. Wenn diese Zeile nie erscheint, verwirft eine Komponente 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 nicht übernommen 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 diesem Format:

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 die Bridge-Zeile gehört. Die zweite Datei 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 stimmt nicht mit dem Identitätsschlüssel überein, den Ihre Bridge präsentiert. Daher lehnt der Client die gerade aufgebaute Verbindung ab.

Wie erreicht eine Bridge tatsächlich Benutzer?

Sie geben Ihre Bridge-Zeile nicht an irgendjemanden weiter. Sobald der Bridge-Authority der Descriptor vorliegt, weist das Verteilungssystem (rdsys, der Nachfolger von BridgeDB) Ihre Bridge einem Distributor zu. Benutzer fragen diesen Distributor nach Bridges. Im August 2026 sind dies die folgenden 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 bei den Anbietern besteht, weil unbegrenzt viele kostenlose Konten es einer zensierenden Stelle ermöglichen würden, alle Bridges aufzuzählen.
• Der Telegram-Bot @GetBridgesBot. Senden Sie /start und danach /obfs4 oder /webtunnel.
• Tor Browser selbst unter Settings und anschließend Connection. Mit "Request bridges" werden Bridges über den moat-Kanal abgerufen.

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: "It can take several days or weeks until you see a consistent set of users." Eine geringe Anzahl von Benutzern in den ersten zwei Wochen ist normal und kein Fehler.

Mit BridgeDistribution none deaktivieren Sie alle diese Wege. Dann können Sie die Bridge-Zeile den benötigten Personen über einen Kanal senden, den die zensierende Stelle nicht überwacht.

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 ss -lntp und lesen Sie das Log auf einen Konfigurationsfehler hin.

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 binden. 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 läuft.

Nichts in /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 auch, ob sich die öffentliche IP-Adresse des Servers geändert hat. Das kann bei einem Neuaufbau bei manchen 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

Meldet sich mein VPS-Provider wegen einer Tor-Bridge?

Eine Bridge ist ein Einstiegspunkt. Der Datenverkehr, der Ihren Server verlässt, wird daher an andere Tor-Relays weitergeleitet und nie an eine Website, die ein Benutzer ausgewählt hat. Ihre IP-Adresse erscheint in keinem Weblog als Quelle einer Anfrage. Genau das führt zu den Beschwerden, mit denen Betreiber von Exit-Relays umgehen müssen. Die Hosting-Regeln unterscheiden sich dennoch. Einige Provider behandeln jeden Tor-Dienst als Sonderfall. Lesen Sie daher vor dem Start die Richtlinie zur akzeptablen Nutzung und tragen Sie eine gelesene 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 mittleres Relay sind es 10 Mbit/s. Die tatsächliche Nutzung beginnt nahe null, weil 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 sich noch niemand mit meiner neuen Bridge verbunden?

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 eine konstante Benutzergruppe bildet. Prüfen Sie, ob der Descriptor veröffentlicht wurde. Das ist die Selbsttest-Zeile in journalctl -u tor@default. Suchen Sie in Relay Search nach Ihrem gehashten Fingerprint und bestätigen Sie, dass BridgeDistribution nicht auf none gesetzt ist.

Sollte ich obfs4 oder WebTunnel ausführen?

Verwenden Sie obfs4, wenn dies Ihre erste Bridge ist: ein VPS, zwei Ports, keine Domain und kein Zertifikat. Verwenden Sie WebTunnel, wenn Datenverkehr mit zufälligem Erscheinungsbild 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 betreiben. Andernfalls würde eine blockierte IP-Adresse gleichzeitig zwei Bridges außer Betrieb setzen.

Was geschieht, 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 zusammen. Ein Client mit der alten Zeile baut daher eine Verbindung zu einem Port auf, an dem kein Dienst lauscht, und bricht ab. Dasselbe gilt, wenn sich die öffentliche IP-Adresse des Servers ändert. Wählen Sie den Port während der Einrichtung und ändern Sie ihn danach nicht mehr.