ガイド

著者 Matt Connor 2026-10-10

VPSでobfs4 Torブリッジを構築する方法

安価なVPS 1台でobfs4 Torブリッジを運用します。torrcの設定、2つのTCPポート、ファイアウォール、動作を示すログ、利用者へのbridge lineの渡し方を解説します。

Tor ブリッジとは何か、なぜ存在するのか

Tor ブリッジは、公開リレー一覧にアドレスが掲載されていない、Tor ネットワークへの入口です。この一覧はコンセンサスと呼ばれる署名済み文書で、誰でもダウンロードできます。検閲者も同じ文書を取得できます。コンセンサスを取得し、そこに記載されたすべてのアドレスを境界で遮断すれば、Tor の遮断には半日もかかりません。ブリッジが存在するのは、公開一覧が弱点になるためです。ブリッジのアドレスは少数ずつ提供されるため、1 回の要求で全体が渡されることはありません。

公開されていないアドレスだけでは十分ではありません。Deep Packet Inspection (DPI) は、アドレスではなく内容に基づいてトラフィックを分類し、TLS (transport layer security) ハンドシェイクの特徴から Tor 接続を識別します。検閲者が一覧を持っていなくても、「これは Tor のように見える」と判断して接続を遮断できます。Pluggable transport はこの特徴を取り除きます。クライアント側で Tor ストリームを別の形式で包み、ブリッジ側で元に戻します。

obfs4 は、ほとんどのブリッジで使用されるトランスポートです。ストリームをヘッダーのない、固定ハンドシェイクも存在しないバイト列に変換するため、DPI が照合できるパターンはありません。また、クライアントを認証します。bridge line 内の cert= の値は、ブリッジが応答する前にクライアントが保持を証明しなければならない鍵です。これにより、アクティブプロービングを防げます。検閲者が 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 プロキシを実行するため、エントリーポイントは常に変化し、検閲者がブロックできる固定アドレスはありません。これでは bridge を運用しません。プロキシを実行するだけで、固定アドレスも不要です。

まず obfs4 から始めてください。後から 2 つ目のアドレスで WebTunnel bridge を追加できます。1 つの IP で両方を実行すると、そのアドレスが 1 つブロックされただけで両方とも利用できなくなります。

ブリッジの運用にはどのようなコストがかかりますか？

グラフTor Project published minimum bandwidth, October 2026

label

min_upstream_mbit

Bridge, minimum

Guard or middle relay, minimum

Guard or middle relay, recommended

このグラフのデータ

[
  {
    "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 年 10 月時点で、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 サービスを特別扱いしているためです。この点で、ブリッジと onion service は対照的です。ブリッジは、そのアドレスに到達でき、最終的にユーザーへ配布されることによってのみ役立ちます。一方、同種の VPS 上で v3 onion service を運用する方法なら、公開 IP を完全に見えない状態にできます。

してはいけないことが 1 つあります。既存の公開 relay を、同じアドレスのままブリッジに変更しないでください。この場合の Tor Project の助言は、「IP address, name and fingerprint」を変更することです。古いアドレスは、検閲者がダウンロードする consensus にすでに含まれているためです。先週まで公開 relay だったブリッジは、すでに blocklist に登録されているブリッジです。

速度よりも uptime が重要です。relay の要件では、「relay が 1 日に 2 時間を超えて停止している場合、その有用性は限られる」と説明されています。この点では、ブリッジは relay より不利です。クライアントが知っているのは、渡されたブリッジ情報だけだからです。Tor Browser は複数の情報を 1 行に 1 つずつ受け付けますが、それらがすべて応答しなくなると、ユーザーは新しい情報を取得する必要があります。あなたのブリッジを再起動すると、そのブリッジを使用しているすべてのユーザーが切断されます。obfs4 ポートに対して Uptime Kuma で TCP ポートチェックを設定し、応答が停止した日に把握できるようにしてください。

Tor Project リポジトリから Tor をインストールする

ディストリビューションのパッケージは更新が遅れるため、最新状態を保つべきセキュリティソフトウェアである bridge には適しません。まず、Tor Project 独自のリポジトリを追加します。

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 file を作成します。Suites: の行にはリリースの codename を指定する必要があるため、記憶で入力せず、システムから取得します。

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

apt update で、指定した codename に対応する Release file がリポジトリにないと表示された場合、Tor Project はそのリリースを提供していません。/etc/apt/sources.list.d/tor.sources を削除し、sudo apt update を再度実行して、ディストリビューションが提供する tor パッケージをインストールします。以降の手順は同じです。

obfs4proxy パッケージは Debian と Ubuntu 自身が提供しています（2026 年 10 月時点で Debian 13 では version 0.0.14）。binary のインストール先を確認してください。その path を設定ファイルに指定します。

command -v obfs4proxy || command -v lyrebird

Upstream ではプロジェクト名を lyrebird に変更したため、新しいパッケージでは /usr/bin/lyrebird がインストールされる場合があります。そのコマンドが出力した path を使用してください。

/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 を公開 consensus ではなく bridge authority に送信するよう tor に指示します。この 1 行によって、relay が一覧に載らなくなります。

ORPort は実際の Tor ポートです。インターネットから到達できる必要があります。tor はこのポートをテストし、テストに成功するまで descriptor の公開を拒否するためです。

ServerTransportPlugin は、tor が実行するコマンドを指定します。tor は子プロセスとして obfs4proxy を起動し、pipe 経由で通信するため、obfs4proxy 自身の service unit はありません。それでも systemctl status tor@default には表示され、tor と同じ unit の CGroup に含まれます。

ServerTransportListenAddr は、obfs4proxy が待ち受けるポートを固定します。この行を省略すると、obfs4proxy は起動時に空いているポートを選びます。ほとんどの再起動後には別のポートが選ばれるため、すでに配布したすべてのブリッジ情報が、何も待ち受けていないポートを指すことになります。その場合、クライアントは接続拒否を受け、再試行を停止します。

ExtORPort auto は extended ORPort を開きます。これは、obfs4proxy が確立済みの接続とクライアントのアドレスを tor に渡すために使用する loopback チャネルです。Tor Project のセットアップガイドでは、すべてのブリッジにこの設定を含めています。これがないと、transport はそのアドレスを tor に通知できないためです。

ContactInfo と Nickname はどちらも公開されます。壊れたブリッジについて Tor Project から連絡を受けるため、読むことのできるアドレスを使用してください。また、目立たずに運用したい場合は、自分を特定できない nickname を選んでください。

BridgeDistribution は、あなたのアドレスをユーザーへ渡す distributor を選択します。使用できる値は https、email、telegram、settings、none、any です。最初のブリッジには any を使用し、システムに決定させてください。自分で配布する private bridge には none を使用します。これにより、アドレスを公開配布から完全に除外できます。

ポートの選択が重要な理由

両方のポートに 9001 を使用することは避けてください。Tor Project もそのように明確に説明しています。9001 は従来の ORPort であり、検閲者がインターネット上でこのポートをスキャンするためです。また、2 つのポートは異なる必要があります。tor と obfs4proxy がそれぞれ独自の listener を bind するためです。

obfs4 のポートとして最も強いのは 443 です。制限されたネットワークでも、送信方向の 443 はほぼ常に開いています。そのため、Web ポート以外の通信をほとんど許可しないフィルターでも、443 は通過させます。ただし、ポートによってプロトコルが偽装されるわけではありません。obfs4 のトラフィックは HTTPS ではなく、依然としてランダムなデータに見えます。接続を Web サイトへのアクセスに見せる役割は WebTunnel が担います。1024 未満のポートに bind するには、追加の手順が必要です。obfs4proxy は root として実行されないためです。

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

各 editor で開いたファイルに、次の 2 行を追加します。

[Service]
NoNewPrivileges=no

capability を設定するだけでは不十分です。systemd の NoNewPrivileges は、プロセスが親プロセスにない権限を取得することを防ぎます。file capability はまさにその権限に該当するため、設定を有効にしたままだと obfs4proxy は 443 への bind に失敗します。

この手順を省略したい場合は、目立たない high port を選び、記録しておいてください。どのポートを選んでも、後から obfs4 ポートを変更してはいけません。ブリッジ情報では、アドレス、ポート、fingerprint、certificate が 1 つに固定されています。そのため、ユーザーの browser にすでに保存されている情報は、ポートを変更した瞬間にすべて使用できなくなります。

両方のファイアウォールでポートを開く

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

両方のポートを開く必要があります。多くのプロバイダーは、ufw が認識できないファイアウォールをコントロールパネル側にも用意しています。サーバー上には存在していてもパネル側にないルールでは、到達不能なブリッジが作成され、ディスクリプターも公開されません。ここで扱う内容のどちらかが初めてであれば、新しい VPS に必要な ufw ルールとLinux で待ち受けポートが実際に意味するものを参照してください。あわせて、鍵と強化した sshd 設定で SSH を制限してください。登録されていないブリッジがあるサーバーでも、パスワード SSH を使っている限り、パスワード SSH のサーバーに変わりはありません。

起動してログを確認する

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

Debian と 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 name の不一致です。両方の directive で obfs4 になっている必要があります。

2つの listener が存在することを確認します。

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 番目のファイルにはハッシュ化された fingerprint が含まれています。これは Relay Search に貼り付けて、ブリッジが稼働しているか、またおおよそのクライアント数を確認するために使用します。両者は互換性がありません。ハッシュ値を含むブリッジ行は、ブリッジが提示する identity key と一致しないため、クライアントは開いた接続を拒否します。

ブリッジは実際にどのようにユーザーへ届くのか

ブリッジの行を誰かに直接渡すわけではありません。descriptor がブリッジ authority に届くと、配布システム（BridgeDB の後継である rdsys）がブリッジを1つの distributor に割り当て、ユーザーはその distributor にブリッジを要求します。2026年10月時点の経路は次のとおりです。

bridges.torproject.org/options のブリッジ Web サイト。「Just give me bridges!」を選ぶと、obfs4 の行がすぐに返されます。captcha はありません。Tor Project は rdsys が BridgeDB に置き換わった際に captcha を廃止し、その変更を2024年12月に発表しました。
Gmail または Riseup のアドレスから bridges@torproject.org にメールを送信すると、ブリッジの行が返信されます。このプロバイダー制限は、無制限の無料アカウントを使って検閲者がすべてのブリッジを列挙できないようにするためです。
Telegram bot の @GetBridgesBot。/start を送信し、その後に /obfs4 または /webtunnel を送信します。
Tor Browser 自体の Settings、次に Connection を開きます。「Request bridges」を選ぶと、moat channel 経由でブリッジを取得します。

新しいブリッジは、セットアップから約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 の案内では、安定した数のユーザーが接続するまでに数日から数週間かかります。descriptor が公開されていることを確認してください。これは journalctl -u tor@default にある自己テストの行です。Relay Search でハッシュ化された fingerprint を検索し、BridgeDistribution が none に設定されていないことも確認してください。

obfs4 と WebTunnel のどちらを実行すべきですか？

初めてブリッジを設定する場合は obfs4 を実行してください。必要なのは 1 台の VPS と 2 つのポートだけで、ドメインも証明書も不要です。ランダムに見えるトラフィック自体がブロックされる環境では WebTunnel を実行してください。WebTunnel には、管理下のドメイン、実際の Web サーバー、有効な TLS 証明書、少なくとも 1 GB の RAM が必要です。両方を実行する場合は、別々のアドレスに配置してください。そうしないと、1 つの IP がブロックされた際に 2 つのブリッジが同時に利用できなくなります。

後から obfs4 のポートを変更するとどうなりますか？

すでに配布されたすべてのブリッジラインが機能しなくなります。ブリッジラインには、アドレス、ポート、fingerprint、証明書が一体として固定されています。そのため、古いラインを保持しているクライアントは、何も待ち受けていないポートへ接続しようとし、接続を諦めます。サーバーのパブリック IP が変わった場合も同じです。セットアップ時にポートを決め、その後は変更しないでください。

#tor#obfs4#bridge #censorship #self-hosting