著者 VPSでobfs4 Tor bridgeを構築する方法
安価なVPS 1台でobfs4 Tor bridgeを構築します。torrcの設定、2つのTCPポート、firewall、動作を示すログ行、利用者へのbridge lineの渡し方を解説します。
Tor bridge とは何か、なぜ存在するのか
Tor bridge は、アドレスが公開リレーリストに掲載されていない Tor ネットワークへの入口です。このリストは consensus と呼ばれる署名付きドキュメントで、誰でもダウンロードできます。検閲者も同じようにダウンロードできます。リストに基づいて Tor をブロックするのに時間はかかりません。consensus を取得し、そこに記載されたすべてのアドレスを境界で遮断すればよいからです。公開リストが弱点になるため、bridge が存在します。bridge のアドレスは少数ずつ配布されるため、1 回の要求で全体が渡ることはありません。
公開されていないアドレスだけでは十分ではありません。Deep packet inspection (DPI) は、アドレスではなく内容に基づいてトラフィックを分類します。DPI は、TLS (transport layer security) handshake の特徴から Tor 接続を識別できます。検閲者がリストを持っていなくても、「これは Tor に見える」と判断して接続を遮断できます。pluggable transport は、この識別材料を取り除きます。クライアント側で Tor のストリームを別の形式で包み、bridge がそれを元に戻します。
obfs4 は、多くの bridge で使用されている transport です。ストリームをヘッダーのない、固定 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 relay には 10 Mbit/s が求められ、16 Mbit/s が推奨されています。これらは公開された要件であり、実測値ではありません。新しいブリッジは通常、数週間にわたって自身の最低要件を大きく下回ります。同じ要件ページでは、relay に月間少なくとも 100 GByte の送信トラフィックも求めています。最小構成のプランでこの量はすでに賄えるため、より大きな構成にする前に、小規模な VPS の実際の月額費用を確認してください。
悪用される可能性は小さく、ここは誤解されやすい点です。ブリッジは最初の hop です。サーバーから出るトラフィックは別の Tor relay に送られ、ユーザーが選んだ Web サイトに直接送られることはありません。あなたの IP アドレスが、見知らぬ人の Web ログでリクエスト元として表示されることもありません。そのため、exit relay の運用者が対応する苦情メールが、ここに届くことはありません。ただし、プロバイダーの acceptable use policy は確認してください。ホストによっては、Tor サービスを特別扱いする場合があります。
してはいけないことが 1 つあります。既存の public relay を同じアドレスのままブリッジに変更しないでください。この場合の Tor Project の助言は、「IP address、name、fingerprint」を変更することです。以前のアドレスは、検閲者がダウンロードする consensus にすでに含まれているためです。先週まで public relay だったブリッジは、すでに blocklist に登録されているブリッジです。
速度よりも uptime が重要です。relay の要件には、「relay が 1 日に 2 時間を超えて停止している場合、その有用性は限定される」とあります。この点では、ブリッジは relay より不利です。各クライアントが持つアドレスは 1 つだけで、fallback がないためです。再起動すると、そのブリッジを利用しているすべてのユーザーが切断されます。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次に、ソースファイルを作成します。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 lyrebird上流プロジェクトでは名称が 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 は、公開コンセンサスではなくブリッジ認証局へ自身のディスクリプターを送信するよう tor に指示します。この 1 行によって、リレーが一覧に掲載されなくなります。
ORPort は実際の Tor ポートです。tor はこのポートに対して到達性をテストし、テストに成功するまでディスクリプターの公開を拒否するため、インターネットから到達できなければなりません。
ServerTransportPlugin は tor に実行するコマンドを指定します。tor は子プロセスとして obfs4proxy を起動し、パイプ経由で通信します。そのため、obfs4proxy 自体の service unit はなく、systemctl status にも表示されません。
ServerTransportListenAddr は obfs4proxy が待ち受けるポートを固定します。この行を省略すると、obfs4proxy は起動時に空いているポートを選びます。多くの再起動後には別のポートが選ばれるため、すでに配布したすべてのブリッジ行が、何も待ち受けていないポートを指すことになります。クライアントでは接続が拒否され、再試行を停止します。
ExtORPort auto は拡張 ORPort を開きます。これは、obfs4proxy が完了した接続をクライアントのアドレスとともに tor へ渡すために使用するループバックチャネルです。Tor Project のセットアップガイドではすべてのブリッジにこの設定を含めています。これがないと、トランスポートはそのアドレスを tor に通知できません。
ContactInfo と Nickname はどちらも公開されます。Tor Project がブリッジの障害について連絡する際に使用するため、確認できるアドレスを指定してください。また、身元を明かしたくない場合は、自分を特定できないニックネームを選んでください。
BridgeDistribution は、ユーザーにアドレスを配布するディストリビューターを選択します。使用できる値は https、email、telegram、settings、none、any です。最初のブリッジでは any を使用し、システムに任せてください。自分で配布する非公開ブリッジには none を使用します。これにより、アドレスを公開配布から完全に除外できます。
ポートの選択が重要な理由
両方のポートに 9001 を使用しないでください。Tor Project が明確にそう説明しています。9001 は従来の ORPort であり、検閲者がインターネット上でこのポートをスキャンするためです。また、tor と obfs4proxy はそれぞれ独自のリスナーに bind するため、2 つのポートは互いに異なる必要があります。
obfs4 に最適なポートは 443 です。制限されたネットワークでも、外向きの 443 はほぼ常に開いています。また、長時間維持される接続も通常の Web セッションに見えます。1024 未満のポートに bind するには追加の手順が 1 つ必要です。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 に bind できません。
この手順を省略する場合は、目立たない高位ポートを選び、記録しておいてください。どのポートを選んでも、後から obfs4 のポートを変更しないでください。ブリッジ行では、アドレス、ポート、フィンガープリント、証明書が 1 つに固定されています。そのため、すでにユーザーのブラウザーに保存されているすべてのコピーが、ポートを変更した時点で動作しなくなります。
両方のファイアウォールでポートを開放する
sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status両方のポートを開放する必要があります。多くのプロバイダーは、ufw が認識できない第 2 のファイアウォールをコントロールパネルで運用しています。サーバー上には存在するものの、パネルには設定されていないルールでは、到達できず、descriptor も公開しない bridge が生成されます。どちらか一方の設定が初めての場合は、新しい VPS に必要な ufw ルールと、Linux で listening port が実際に意味するものを参照してください。あわせて、鍵と強化した 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'1 行目は到達性テストに成功し、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 と一致しないため、クライアントは開いた接続を拒否します。
ブリッジは実際にどのように利用者へ届くのでしょうか？
ブリッジの行を誰かに直接渡す必要はありません。ディスクリプターがブリッジ認証局に届くと、配布システム（BridgeDB の後継である rdsys）がブリッジを1つのディストリビューターに割り当てます。利用者は、そのディストリビューターにブリッジを要求します。2026年8月時点の経路は次のとおりです。
- bridges.torproject.org/options の Web フォーム。captcha の後にブリッジ行が表示されます。
- Gmail または Riseup のアドレスから bridges@torproject.org にメールを送信する方法。ブリッジ行が返信されます。無制限に作成できる無料アカウントを使うと、検閲者がすべてのブリッジを列挙できるため、プロバイダーを制限しています。
- 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 を確認し、設定エラーがないかログを確認します。
登録された transport に、指定していないポートが表示される。 tor が ServerTransportListenAddr を無視しています。transport 名は 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 が transport を起動していません。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 の案内では、継続的に利用するユーザーが現れるまでには数日から数週間かかります。descriptor が公開されたことを確認してください。これは journalctl -u tor@default にある自己テストの行です。Relay Search でハッシュ化された fingerprint を検索し、BridgeDistribution が none に設定されていないことを確認してください。
obfs4 と WebTunnel のどちらを実行すべきですか？
初めてブリッジを構築する場合は obfs4 を実行してください。必要なのは VPS 1 台とポート 2 つだけで、ドメインも証明書も必要ありません。ランダムに見えるトラフィック自体がブロックされる環境では WebTunnel を実行してください。WebTunnel には、管理しているドメイン、実際の Web サーバー、有効な TLS 証明書、少なくとも 1 GB の RAM が必要です。両方を実行する場合は、別々のアドレスに配置してください。そうしないと、1 つの IP がブロックされたときに 2 つのブリッジが同時に利用できなくなります。
後から obfs4 のポートを変更するとどうなりますか？
すでに配布されたすべてのブリッジ行が機能しなくなります。ブリッジ行には、アドレス、ポート、fingerprint、証明書がまとめて固定されています。そのため、古い行を保持しているクライアントは、何も待ち受けていないポートに接続しようとして、接続を断念します。サーバーの公開 IP が変わった場合も同様です。セットアップ時にポートを決め、その後は変更しないでください。