著者 VPSでobfs4 Tor bridgeを構築する方法
安価なVPS 1台でobfs4 Tor bridgeを運用します。torrcの設定、ポート選び、ファイアウォール、成功を示すログ行、利用者へのbridge lineの渡し方を解説します。
Tor bridge とは何か、なぜ存在するのか
Tor bridge は、アドレスが公開 relay 一覧に掲載されていない Tor ネットワークへの入口です。この一覧は consensus と呼ばれる署名付き文書で、誰でもダウンロードできます。検閲者も同じ文書を取得できます。consensus を取得し、そこにあるすべてのアドレスを境界で遮断すれば、Tor の遮断は半日で完了します。公開一覧が弱点になるため、bridge が存在します。bridge のアドレスは一度に少数ずつ配布されるため、1 回の要求で全体が渡されることはありません。
一覧に載っていないアドレスだけでは、対策として不十分です。Deep packet inspection (DPI) は、アドレスではなく内容に基づいてトラフィックを分類します。DPI は、TLS (transport layer security) handshake の特徴から Tor 接続を認識します。検閲者は一覧を持っていなくても、「これは Tor のように見える」と判断して接続を遮断できます。Pluggable transport を使うと、この信号を取り除けます。クライアント側で Tor stream を別の形式で包み、利用している bridge がそれを元に戻します。
obfs4 は、多くの bridge で使われている transport です。stream をヘッダーも固定された handshake もないバイト列に変換するため、DPI が一致させられるパターンがありません。また、クライアントを認証します。bridge line 内の cert= の値は、bridge が応答する前にクライアントが保持を証明しなければならない key です。これにより active probing を防げます。検閲者が、Tor を話すか確認するためにあなたのアドレスへ接続しても、応答はなく、何も知ることができません。
どの pluggable transport を実行すべきか
- obfs4 には、1 台の VPS、2 つの TCP ポート、ドメイン名が不要です。実用的で最も簡単に実行できる構成であり、このガイドではこれを扱います。
- WebTunnel は、実在する Web サイトへの通常の HTTPS トラフィック内に接続を隠します。Tor Project は、静的な IPv4 アドレス、管理下にあるドメイン、NGINX や Apache などの稼働中の Web サーバー、有効な TLS 証明書、最低 1 GB の RAM（4 GB 推奨）を要件として挙げています。ランダムに見えるトラフィック自体が疑われるネットワークに適しています。Web 閲覧以外をほとんど許可しない国でも、HTTPS は許可されているためです。
- Snowflake は別の形態の協力です。ボランティアが短時間だけ有効な WebRTC プロキシを実行するため、入口が常に変わり、検閲者がブロックできる固定アドレスはありません。これに対してブリッジを運用する必要はありません。プロキシを実行するだけで、固定アドレスも不要です。
まず obfs4 から始めます。後から 2 つ目のアドレスで WebTunnel ブリッジを追加できます。1 つの IP で両方を実行すると、1 つのアドレスがブロックされた時点で両方とも利用できなくなります。
ブリッジの運用にはどのようなコストがかかりますか？
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
}
]2026年8月時点で、Tor Project はブリッジに対して、上りと下りで少なくとも 1 Mbit/s の帯域幅を求めています。Guard または Middle リレーには 10 Mbit/s が求められ、16 Mbit/s が推奨されています。これらは公表された要件であり、実測値ではありません。新しいブリッジの帯域は、通常、数週間にわたって自身の最低要件を大きく下回ります。同じ要件ページでは、リレーに月間100 GByte以上の送信トラフィックも求めていますが、最小構成のプランですでに対応できます。そのため、より大きな構成にする前に、小規模な VPS の実際の月額費用を確認してください。
悪用される可能性は小さいですが、ここは誤解されやすい点です。ブリッジは最初の hop です。サーバーから出るトラフィックは別の Tor リレーへ送られ、ユーザーが選んだ Web サイトへ直接送られることはありません。あなたの IP アドレスが、リクエスト元として第三者の Web ログに現れることもありません。そのため、Exit リレーの運用者が対応する苦情メールが、ここに届くことはありません。ただし、プロバイダーの利用規約は確認してください。ホストによっては、Tor サービスを特別扱いする場合があります。この点で、ブリッジと Onion Service は対照的です。ブリッジは、そのアドレスに到達でき、最終的に利用者へ配布されるからこそ役立ちます。一方、同種の VPS 上で v3 Onion Service を運用する場合は、パブリック IP が外部から見えない間だけ役立ちます。
してはいけないことが1つあります。既存のパブリックリレーを、同じアドレスのままブリッジへ変更しないでください。この場合、Tor Project は「IP address, name and fingerprint」を変更するよう案内しています。古いアドレスは、検閲側がダウンロードするコンセンサスにすでに含まれているためです。先週までパブリックリレーだったブリッジは、すでにブロックリストに登録されているブリッジです。
速度よりも稼働時間が重要です。リレーの要件では、「リレーが1日に2時間を超えて停止している場合、その有用性は限定される」とされています。この点では、ブリッジはリレーより不利です。各クライアントが持つアドレスは1つだけで、フォールバックもないためです。再起動すると、そのブリッジを利用しているすべてのユーザーが切断されます。obfs4 ポートに対して Uptime Kuma で TCP ポートチェックを設定し、応答が停止した当日に把握できるようにしてください。
Tor Project のリポジトリから Tor をインストールする
ディストリビューションのパッケージは更新が遅れるため、ブリッジで使用するセキュリティソフトウェアは最新の状態に保つ必要があります。まず、プロジェクト独自のリポジトリを追加します。
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次に、source ファイルを作成します。Suites: の行にはリリースのコードネームを指定する必要があります。そのため、記憶で入力せず、システムから取得します。
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 obfs4proxyapt update で、指定したコードネーム用の Release ファイルがリポジトリにないと表示された場合、そのリリースは Tor Project で提供されていません。/etc/apt/sources.list.d/tor.sources を削除し、もう一度 sudo apt update を実行して、ディストリビューションが提供する tor パッケージをインストールします。以下の手順はすべて同じです。
obfs4proxy パッケージは Debian と Ubuntu 自身が提供しています（2026 年 8 月時点で、Debian 13 ではバージョン 0.0.14）。バイナリが配置された場所を確認してください。このパスを設定ファイルに指定します。
command -v obfs4proxy || command -v lyrebirdUpstream ではプロジェクト名を lyrebird に変更したため、新しいパッケージでは代わりに /usr/bin/lyrebird がインストールされる場合があります。そのコマンドが出力したパスを使用してください。
/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これらの各行には、それぞれ異なる失敗原因が関係しています。1 行ずつ確認してください。
BridgeRelay 1 は、公開コンセンサスではなくブリッジ認証局へ descriptor を送信するよう tor に指示します。この 1 行によって、リレーが一覧に載らなくなります。
ORPort は実際の Tor ポートです。tor はこのポートをテストし、テストに成功するまで descriptor の公開を拒否するため、インターネットから到達できなければなりません。
ServerTransportPlugin は、tor が実行するコマンドを指定します。tor は obfs4proxy を子プロセスとして起動し、パイプ経由で通信します。そのため、obfs4proxy 自体の service unit はなく、systemctl status にも表示されません。
ServerTransportListenAddr は、obfs4proxy が待ち受けるポートを固定します。この行を省略すると、obfs4proxy は起動時に空いているポートを選びます。多くの再起動後には別のポートになるため、すでに配布したすべてのブリッジ行が、何も待ち受けていないポートを指すことになります。そのクライアントは接続拒否を受け、再試行を停止します。
ExtORPort auto は拡張 ORPort を開きます。これは、obfs4proxy が確立済みの接続をクライアントのアドレスとともに tor へ戻すために使用する loopback チャネルです。Tor Project のセットアップガイドではすべてのブリッジにこれを設定しています。これがないと、トランスポートはそのアドレスを tor に通知できません。
ContactInfo と Nickname はどちらも公開情報です。壊れたブリッジについて Tor Project から連絡を受ける宛先となるため、読むアドレスを指定してください。目立たないようにしたい場合は、自分を特定できない nickname を選んでください。
BridgeDistribution は、ユーザーにアドレスを配布する distributor を選択します。指定できる値は https、email、telegram、settings、none、any です。最初のブリッジでは any を使用し、システムに決定させてください。自分で配布する非公開ブリッジには none を使用します。これにより、アドレスが公開配布されることはありません。
ポートの選択が重要な理由
両方のポートに 9001 を使用しないでください。Tor Project が明確にそう説明しています。9001 は従来の ORPort であり、検閲システムがインターネット上でこのポートをスキャンするためです。また、2 つのポートは互いに異なる必要があります。tor と obfs4proxy がそれぞれ独自のリスナーをバインドするためです。
obfs4 に最適なポートは 443 です。ほぼすべての制限されたネットワークで外向きの 443 は開いており、そこへの長時間接続は通常の Web セッションに見えます。1024 未満のポートにバインドするには追加の手順が必要です。obfs4proxy は root として実行されないためです。
sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service各エディターで開いたファイルに、次の 2 行を追加します。
[Service]
NoNewPrivileges=noケーパビリティを設定するだけでは不十分です。systemd の NoNewPrivileges は、親プロセスが持っていなかった権限をプロセスが取得することを防ぎます。ファイルケーパビリティはまさにその権限に該当するため、この設定が有効な間は obfs4proxy が 443 にバインドできません。
この手順を省略する場合は、目立たない高いポート番号を選び、記録しておいてください。どのポートを選んでも、後から obfs4 のポートを変更しないでください。ブリッジ行では、アドレス、ポート、フィンガープリント、証明書が一体として固定されます。そのため、ユーザーのブラウザーにすでに保存されているコピーは、ポートを変更した時点で使用できなくなります。
両方のファイアウォールでポートを開放する
sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status両方のポートを開放する必要があります。多くのプロバイダーは、ufw が認識できないファイアウォールをコントロールパネルにも用意しています。サーバー上にだけ存在し、コントロールパネルにないルールでは、到達できず、descriptor も公開されない bridge が作成されます。いずれかの設定が初めてであれば、新しい VPS に必要な ufw ルールと、Linux で listening port が実際に意味するものを確認してください。あわせて、cryptographic key と強化した sshd 設定で SSH を制限してください。パスワードによる SSH 接続を許可したサーバーでは、bridge を一覧に表示しない設定にしても、パスワードによる SSH 接続を許可したサーバーであることに変わりはありません。
起動してログを確認する
sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@defaultDebian と Ubuntu には 2 つの unit があります。tor.serviceは小さなラッパーで、tor@default.serviceが実際に処理を実行するプロセスです。そのため、journalctl -u torの内容はほとんど空に見えます。確認したいログはtor@defaultにあります。
動作したことを示す行は 2 つあります。
Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'最初の行は、到達性テストに成功し、descriptor がブリッジ認証局へ送信されたことを示します。この行が表示されない場合、インターネットとサーバーの間にある何らかの機器または設定が、ORPort へのネットワークトラフィックを破棄しています。2 行目には、設定したポートが表示されている必要があります。ここに別のポートが表示される場合、tor はServerTransportListenAddrを適用していません。通常の原因は、transport 名が一致していないことです。両方のディレクティブでobfs4と記述する必要があります。
2 つのリスナーが存在することを確認します。
sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'ブリッジ行はどこにありますか？
obfs4proxy は、tor のデータディレクトリにテンプレートを書き込みます。
sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txtこのディレクトリの所有者は tor ユーザーで、モードは 700 です。そのため、sudo がないと Permission denied になります。ファイルには、次の形式の行が含まれています。
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0<IP ADDRESS> をサーバーのパブリックアドレスに、<PORT> を ORPort ではなく obfs4 ポートに、<FINGERPRINT> を tor がデータディレクトリに書き込んだ identity fingerprint に置き換えます。
sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint最初のファイルには、ブリッジ行に記載する nickname と identity fingerprint が含まれています。2 番目のファイルには hashed fingerprint が含まれています。この値を Relay Search に貼り付けると、ブリッジが稼働しているか、およびおおよその接続クライアント数を確認できます。この 2 つは互換性がありません。hashed value を含むブリッジ行は、ブリッジが提示する identity key と一致しないため、クライアントは確立した接続を拒否します。
ブリッジは実際にはどのように利用者へ届くのか？
ブリッジの行を誰かに直接渡すわけではありません。descriptor がブリッジ機関に届くと、配布システム（BridgeDB の後継である rdsys）がブリッジを 1 つの配布元に割り当て、利用者はその配布元にブリッジを要求します。2026 年 8 月時点の経路は次のとおりです。
- bridges.torproject.org/options の Web フォーム。captcha の後にブリッジの行が表示されます。
- Gmail または Riseup のアドレスから bridges@torproject.org に送信するメール。ブリッジの行が返信されます。無制限に作成できる無料アカウントを使えば、1 人の検閲者がすべてのブリッジを列挙できるため、プロバイダーを制限しています。
- Telegram bot の @GetBridgesBot。
/startを送信し、続けて/obfs4または/webtunnelを送信します。 - Tor Browser の Settings、続いて Connection。ここで "Request bridges" を選ぶと、moat チャネル経由でブリッジを取得します。
新しいブリッジは、セットアップから約 3 時間後に Relay Search に表示されます。利用者が現れるまでには、さらに長い時間がかかります。Tor Project は、「一貫した利用者の集合を確認できるまで、数日から数週間かかる場合があります」と説明しています。最初の 2 週間に利用者が少なくても正常であり、障害ではありません。
BridgeDistribution none を設定すると、これらすべての配布から除外されます。その場合、ブリッジの行は必要とする人に、検閲者が読み取れないチャネルを通じて自分で送信します。
動作しない場合
ログに自己テストの行がない。 ORPort に到達できません。別のマシンから nc -vz your.ip 8443 でテストします。応答がない場合はパケットが破棄されているため、ufw とプロバイダーの管理パネルを確認します。接続拒否の場合は tor が待ち受けていないため、ss -lntp を確認し、設定エラーがないかログを確認します。
登録されたトランスポートに、選択していないポートが表示される。 tor が ServerTransportListenAddr を無視しています。トランスポート名は ServerTransportPlugin に記載された名前と完全に一致し、どちらも obfs4 である必要があります。
obfs4proxy がポート 443 に bind できない。 getcap /usr/bin/obfs4proxy で capability を確認し、systemctl show tor@default -p NoNewPrivileges で override が unit に反映されていることを確認します。NoNewPrivileges=yes と表示された場合、drop-in は実行されていない unit に配置されています。
/var/lib/tor/pt_state/ の中に何もない。 tor がトランスポートを起動していません。ServerTransportPlugin のパスが間違っていることを意味します。command -v obfs4proxy の出力と比較します。
変更後にクライアントが接続できなくなった。 アドレスまたは obfs4 のポートを変更すると、すでに配布したすべての bridge line が無効になります。サーバーのパブリック IP も変わっていないか確認します。一部のプロバイダーでは、再構築時に IP が変わります。
tor がまったく起動しない。 sudo -u debian-tor tor --verify-config -f /etc/tor/torrc を実行します。ファイルを解析し、問題のある行を表示します。実行中のサービスには影響しません。
FAQ
VPS プロバイダーから Tor ブリッジについて苦情を受けますか？
ブリッジはエントリーポイントです。そのため、サーバーから出るトラフィックは他の Tor リレーへ送られ、ユーザーが選択したサイトへ直接送られることはありません。あなたの IP アドレスがリクエスト元として誰かの Web ログに記録されることもありません。これが、出口リレーの運用者が受ける苦情の原因です。ホスティングの規約はプロバイダーによって異なります。Tor サービスを特別扱いするプロバイダーもあるため、開始前に利用規約を確認し、確認したアドレスを ContactInfo に入力してください。
Tor ブリッジはどの程度の帯域幅を使用しますか？
公開されている最小値は、上下方向とも 1 Mbit/s です。ガードリレーまたは中間リレーでは 10 Mbit/s です。実際の使用量はほぼゼロから始まります。ブリッジが運ぶのは、ディストリビューターから接続先として案内されたユーザーのトラフィックだけだからです。上限を明確に設定する場合は、torrc で RelayBandwidthRate と RelayBandwidthBurst を設定してください。
新しく作成したブリッジに誰も接続しないのはなぜですか？
ブリッジが Relay Search に表示されるまでには約 3 時間かかります。Tor Project の案内では、利用者が安定して接続するまで数日から数週間かかるとされています。journalctl -u tor@default にある自己テストの行で descriptor が公開済みであることを確認し、Relay Search でハッシュ化された fingerprint を検索してください。また、BridgeDistribution が none に設定されていないことを確認してください。
obfs4 と WebTunnel のどちらを実行すべきですか？
初めてブリッジを構築する場合は obfs4 を実行してください。必要なのは VPS 1 台、ポート 2 個、ドメインなし、証明書なしの構成です。ランダムに見えるトラフィック自体がブロックされる環境では WebTunnel を実行してください。WebTunnel には、管理しているドメイン、実際の Web サーバー、有効な TLS 証明書、最低 1 GB の RAM が必要です。両方を実行する場合は、別々のアドレスに配置してください。そうしないと、1 つの IP がブロックされた際に 2 つのブリッジが同時に利用できなくなります。
後から obfs4 のポートを変更するとどうなりますか？
すでに配布されたすべてのブリッジ行が機能しなくなります。ブリッジ行には、アドレス、ポート、fingerprint、証明書が一体として指定されています。そのため、古い行を保持しているクライアントは、何も待ち受けていないポートへ接続しようとし、接続を断念します。サーバーのパブリック IP が変わった場合も同様です。セットアップ時にポートを決定し、後から変更しないでください。