著者 VPSでTorリレーを構築する方法
Linux VPSでGuardまたはMiddle Torリレーを構築します。torrc設定、従量課金を守る帯域幅制限、nyx監視、新規リレーの合意形成が遅い理由を解説します。
VPS 上の Tor リレーの役割
Tor リレーは、パブリック IP アドレスを持つマシン上で動作し、他の利用者の暗号化されたトラフィックを転送する Tor デーモンです。ディレクトリ権威がこのリレーを公開し、Tor クライアントはこのリレーを経由するサーキットを構築します。Guard リレーまたは Middle リレーは、トラフィックを別のリレーに渡すだけです。そのため、他者に代わって Web サイトへの接続を開くことはありません。この点が、abuse メールを受け取らず、一般的な VPS に適した貢献である理由です。リレーは他者のトラフィックを運ぶだけで、自身のコンテンツを公開しません。自分のサイトをネットワーク上で公開したいのであって、そのためにパケットを転送したいのではない場合は、同じ tor デーモンで nginx の背後で v3 onion service を実行するという別の役割になります。リレーを実行しても、自分自身のブラウジングのプライバシーは向上しません。これは別の問題であり、多くの人が期待するほど効果は大きくありません。SearXNG のセルフホストで実際に隠せる情報を見ると、サービスを自分の VPS に移すことで得られる効果の目安が分かります。
作業は簡単です。1 つのパッケージ、15 行の設定、1 つのファイアウォールルール、1 回の再起動で済みます。このガイドの残りでは、問題になりやすい点を扱います。従量課金プランでの帯域幅の計算と、正常に動作している新しいリレーが 1 週間にわたって停止しているように見える理由です。
Guard、middle、bridge、exit: インストール前に選択する
1 つの daemon で、4 つの役割をすべて担えます。どの役割になるかは、設定と directory authority によって決まります。
- Middle relay。 Guard から traffic を受け取り、別の relay に転送します。destination site には接続しません。新しい relay はすべて、最初はこの役割になります。
- Guard relay。 同じ設定に、フラグを 1 つ追加したものです。directory authority は、十分な期間にわたって高速かつ安定している relay に Guard フラグを付与します。自分で選ぶものではありません。条件を満たして取得するものであり、以下の設定がその条件を満たすための基盤になります。
- Bridge。 public directory から意図的に除外し、Tor がブロックされている場所のユーザーに非公開で配布する relay です。4 つの役割の中で最も小さな負担で済みます。必要な bandwidth は少なく、public listing もありません。計画が小規模なら、適切な最初の選択肢です。ただし、daemon と並行して obfs4 proxy を実行し、torrc に別の設定行を追加する必要があります。安価な VPS で obfs4 bridge を構成する方法では、最後にユーザーへ bridge line を渡す方法も含めて説明しています。
- Exit relay。 最後の hop であり、destination site への接続を開きます。ユーザーが行うすべての request はあなたの IP address から送信されるため、abuse report や警察からの照会は、その address の所有者に届きます。
Exit は、汎用 VPS で実行してはいけない唯一の役割です。Exit は、事前にその mail を受け取ることに同意した provider 上でのみ実行してください。専用の IP address と公開された abuse contact も必要です。一般的な hosting terms では Exit が禁止されているため、無視すると通常は server が停止され、IP address を失います。それでもこの役割を選ぶ場合は、Exit relay の実際の運用内容で、Exit に対応する host の探し方、exit policy と reverse DNS の設定方法、mail が届いたときの対応を説明しています。Guard または middle relay なら、同じ user traffic を扱いながら、こうした exposure はありません。
以下では、guard/middle relay を構築します。ExitRelay 0 が設定をこの役割に限定する行です。
開始前にVPSに必要なもの
Tor Project は、リレーに必要な要件を公開しています。2026年8月時点では、リレー用の公開 IPv4 アドレスが1つ、各方向で少なくとも10 Mbit/s（推奨は16 Mbit/s）の帯域幅、月間で少なくとも100 GBの送信トラフィック、40 Mbit/s未満では512 MB、40 Mbit/s以上では1 GBの RAM が必要です。稼働時間に固定のルールはありません。ただし、1日2時間未満しか稼働しないリレーは、ネットワークにとってほとんど役に立ちません。
10 Mbit/sという数値は回線の性能を示しており、設定値ではありません。その速度に対応できるポートが必要です。回線のどれだけをリレーに割り当てるかは、月間の転送量上限を基に別途決めます。設定を変更する前に、契約プランを確認してください。まだサーバーを選んでいる場合は、VPSの実際の月額料金で転送量上限の販売方式を確認できます。また、VPSの実際のネットワークスループットを測定するでは、販売ページを信用せず、iperf3を使って回線性能を調べる方法を説明しています。
最初にマシンを堅牢化してください。リレーは公開アドレス上で動作する公開サービスです。そのため、アドレスを公開してから数分以内にスキャンされます。SSHを鍵認証と堅牢化したsshd設定に限定する作業は10分で完了し、リレーを起動する前に行うべきです。起動後に実施してはいけません。
Tor Project のリポジトリから tor をインストールする
ディストリビューションのパッケージではなく、Tor Project 独自の apt リポジトリを使用します。リレーのコードは安定版のリリースより速いペースで更新されるため、修正はこのリポジトリに先に反映されます。ディストリビューションのパッケージは、リリース間で遅れます。
sudo apt update
sudo apt install -y apt-transport-https gnupg wget署名鍵を追加してから、リポジトリを追加します。コードネームはマシンから読み取るため、同じブロックを Ubuntu 24.04 (noble) と Debian 13 (trixie) で使用できます。
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
| gpg --dearmor \
| sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null
CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "$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: $CODENAME
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
tor --versiontor --version は、インストールしたばかりのバージョンを表示します。apt update が代わりに NO_PUBKEY エラーを表示した場合、dearmored key が Signed-By: 行で指定されたパスにありません。そのため、apt はリリースファイルを検証するための鍵を使用できません。deb.torproject.org-keyring パッケージは後で重要になります。このパッケージは署名鍵を通常のパッケージとして提供するため、鍵がローテーションされても apt は動作し続けます。
自動アップグレードを有効にして、新しい origin を認識させます。
sudo apt install -y unattended-upgrades apt-listchangesUbuntu では、/etc/apt/apt.conf.d/50unattended-upgrades の Allowed-Origins ブロックに Tor の origin を追加します。
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
"TorProject:${distro_codename}";
};Debian では、同じファイルで Origins-Pattern を使用します。追加する行は "origin=TorProject"; です。sudo unattended-upgrade --debug --dry-run で結果を確認します。このコマンドは対象となる origin を表示するだけで、何も書き込みません。
重要な torrc 設定
パッケージをインストールすると、コメントが多く付いた長い /etc/tor/torrc が配置されます。リレーに必要な行は数行だけです。ファイルの末尾に追加します。
Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0Nickname は 1 文字以上 19 文字以下で、使用できるのは英字と数字だけです。ネットワーク全体で一意ではなく、あなたの識別情報でもありません。識別情報になるのは fingerprint です。検索ボックスで自分のリレーを見つけるための名前なので、電話で綴りを伝えやすいものを選びます。
ContactInfo は、誰でもダウンロードできる公開文書である relay descriptor に記載されます。そのため、このアドレスは収集されます。2 年後も確認できるアドレスを使用し、必要であれば難読化してください。Tor Project がリレーの問題を通知できる経路は、これだけです。
ORPort 9001 は、他のリレーやクライアントが接続するポートです。9001 が一般的です。もう 1 つの一般的な選択肢は 443 です。一部の制限されたネットワークでは、外向きの 443 だけが許可されるため、ここで待ち受けるリレーには、より多くのクライアントが接続できます。ただし、同じサーバー上の別のサービスがそのポートを必要としない場合に限り、443 を選択します。
SocksPort 0 は、ローカルの SOCKS プロキシを無効にします。リレーはこれを使用しないため、サーバー上の待ち受けソケットも 1 つ減ります。ExitRelay 0 は、この意図をファイルに明示します。このリレーはユーザーの代わりに宛先へ接続することがなく、後から設定を読む人がデフォルト値から意図を推測する必要もありません。
VPS に IPv6 アドレスがある場合は、ORPort の行を 2 行目として追加します。Tor は IPv4 のように IPv6 の「任意の」アドレスへ bind できないため、アドレスを角括弧で囲んで記述します。
ORPort 9001
ORPort [2001:db8::1]:90011 GB の VPS では、MaxMemInQueues 512 MB を追加します。Tor は、サーバー上で認識したメモリ量を基にキューの上限を決定します。小規模な共有サーバーでは、その値が使用させたい量を上回ることがあります。上限を自分で設定すると、負荷が高いときに tor はキューに入った cell を破棄します。そのため、キューが増え続けて kernel にプロセスを強制終了されるのではなく、リレーは稼働を継続できます。
ファイアウォールで ORPort を開放する
受信方向では、ORPort にインターネット上のどこからでも到達できる必要があります。送信方向では、リレーに制限を設けないでください。リレーは多数の異なるポートで数千台の他のリレーへ接続するため、送信許可リストを設定すると、気付かないうちに機能が大きく制限されます。
sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose次に、プロバイダー独自のネットワークファイアウォールを確認します。多くのコントロールパネルでは仮想マシンの前段でパケットフィルターが動作しています。そのため、ufw で追加したルールはそこで適用されず、サーバー上ではポートが開いているのに、外部からは閉じている状態になります。ufw を初めて使う場合は、すべての VPS に設定すべき ufw ルールで、デフォルトポリシーとルールの照合順序を確認できます。
帯域幅をプランに合わせて設定する
マニュアルでは、RelayBandwidthRate を独立したトークンバケットとして説明しています。これは「このノードで中継するトラフィックの平均受信帯域幅を指定した bytes per second に制限し、平均送信帯域幅も同じ値に制限する」ものです。ここは読み違えないでください。制限は受信と送信に個別に適用されます。1 Mbit/s に設定したリレーは、同時に 1 Mbit/s を受信し、1 Mbit/s を送信できます。プロバイダーが両方向を計測する場合、請求対象はその合計です。
The data behind this chart
[
{
"label": "1 Mbit/s",
"torrc_rate": "125 KBytes",
"gb_per_day": 21.6,
"gb_per_month": "648"
},
{
"label": "2 Mbit/s",
"torrc_rate": "250 KBytes",
"gb_per_day": 43.2,
"gb_per_month": "1,296"
},
{
"label": "5 Mbit/s",
"torrc_rate": "625 KBytes",
"gb_per_day": 108,
"gb_per_month": "3,240"
},
{
"label": "10 Mbit/s",
"torrc_rate": "1250 KBytes",
"gb_per_day": 216,
"gb_per_month": "6,480"
},
{
"label": "20 Mbit/s",
"torrc_rate": "2500 KBytes",
"gb_per_day": 432,
"gb_per_month": "12,960"
}
]これらの 5 行は測定値ではなく計算値です。リレーが 30 日間、両方向で指定された速度を維持した場合の通信量を示しています。実際のリレーは、多くの時間で上限を下回ります。特に最初の数週間はその傾向が強くなります。この表は、収まらない設定を除外するために使ってください。ギガバイト単位の請求額を予測するためのものではありません。
各方向が 1 Mbit/s の場合、リレーは 1 日あたり約 21.6 GB を転送します。そのため、30 日の月では従量課金対象の通信量が約 648 GB になります。これは 1 TB の利用枠に収まり、更新やバックアップの余裕も残ります。2 Mbit/s に上げると、1 か月の通信量は 1,296 GB になり、1 TB プランをすでに超えます。最後の行の 20 Mbit/s では、1 か月に 12,960 GB が必要になるため、従量課金のないポートを使用してください。プロバイダーが送信トラフィックだけを課金する場合は、すべての数値を半分にします。速度を設定する前に、どちらの課金方式かを確認してください。結果は 2 倍異なります。
次に設定を行います。まずレートを制限し、その後でクォータを設定します。
RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00RelayBandwidthBurst はトークンバケットのサイズです。平均レートを維持しながら、短時間のスパイクをレート以上に許容します。通常はレートの約 2 倍が適切です。
AccountingRule は、多くの運用者が見落とす行です。デフォルトは max で、クォータに対して受信と送信のうち大きい方を計測します。デフォルトのままでは、AccountingMax 400 GBytes により受信 400 GB と送信 400 GB が許可されます。両方向を計測する課金では、合計 800 GB です。AccountingRule sum は読み取りと書き込みの合計を 1 つのクォータに対して計測します。これは実際の転送量に基づく利用枠と同じ方式です。
AccountingStart も記述してください。AccountingMax だけを単独で記述してはいけません。クォータは数値で、start 行はクォータがリセットされる期間を指定します。期間のないクォータでは、リレーは復帰させる仕組みがなく休止したままになります。
休止は大まかな制御です。クォータを使い切ると、tor はこれをログに記録し、作業の受け付けを停止します。
Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted次の期間が始まった瞬間にリレーが復帰するわけでもありません。Tor は直前のクォータを消費した速度を追跡し、新しい期間内のランダムな時点を復帰時刻に選びます。数千のリレーが同じ秒にネットワークへ戻ることを防ぐためです。毎月最後の 1 週間に消えるリレーは、ディレクトリオーソリティが評価する安定性を失い続けます。上限に到達しないように RelayBandwidthRate を設定し、請求額を保護する最後の手段として AccountingMax を維持してください。
リレーを起動し、到達可能であることを確認する
sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50数分以内に、ログに次の行が含まれるはずです。
Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.この文は、他のリレーがあなたの ORPort に接続し、そこを経由する回線を構築したことを示します。この文が表示されるまでは、リレーはディレクトリに登録されず、トラフィックをまったく中継しません。失敗すると、次のように表示されます。
Your server has not managed to confirm reachability for its ORPort(s) at 203.0.113.10:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.順番に確認します。ORPort は ufw で開いていますか。プロバイダー側に別のネットワークファイアウォールがある場合、そこでも開いていますか。そのメッセージに表示されたアドレスは、NAT 構成のプライベートアドレスではなく、インターネットから実際に到達できるアドレスですか。別のマシンから nc -vz 203.0.113.10 9001 を使ってポートをテストします。Tor は自動的にセルフテストを繰り返すため、ファイアウォールを修正すれば自動的に検出されます。再起動すれば、すぐに再テストできます。
リレーの永続的な識別情報は fingerprint です。
sudo cat /var/lib/tor/fingerprintdescriptor が公開されてから約 3 時間後、リレーは Relay Search に表示されます。nickname を検索するか、fingerprint を貼り付けます。このページには、ネットワークから見たリレーの状態が表示されます。保持している flag、authority が割り当てる weight、公開している version を確認できます。
新しい Tor リレーのトラフィックがほとんどないのはなぜですか？
ネットワークがまだそのリレーを測定しておらず、測定には数週間かかるためです。Tor Project はこの増加過程を4段階で説明しています。この説明を読んでいない運用者は、リレーが故障していると判断し、設定を変更し始めます。
最初の3日間、リレーは未測定の状態です。リレーは自己テストの結果を報告しますが、directory authority は公開される重みを20 KBに制限します。そのため、クライアントに選択されることはほとんどありません。3日目ごろから8日目ごろまでは、bandwidth authority が実際に帯域幅を測定し、重みが増加します。ただし、まったく新しいリレーを最初の hop に選ぶクライアントはいないため、この期間は middle hop としてのみ使用されます。
8日目ごろになると、リレーは Guard フラグの対象になります。このフラグを取得するとトラフィックが減少するため、誰もが驚きます。クライアントは、すでに Guard が使用中であると想定し、middle hop を選ぶ際に Guard を避けます。そのため、リレーは Guard のトラフィックを得る前に middle のトラフィックを失います。クライアントが Guard セットをローテーションするまで、トラフィックは回復しません。この処理には数週間かかります。およそ68日後には、リレーを削除するクライアントと追加するクライアントが均衡し、定常状態に達します。
したがって、現実的な見込みは、3日間は何もなく、1週間後に変化が現れ、2か月後に実際の負荷が発生するというものです。設定は1つだけ変更し、その結果を確認するために1週間待ちます。自分でホストする Uptime Kuma のステータスページで port 9001 に対して TCP check を実行するほうが、不安から生じる作業としては有効です。これは、実際に制御できる「port が引き続き応答しているか」という問いに答えられるためです。
nyx でリレーを監視する
nyx は、稼働中のリレーを監視するターミナルツールです。tor の control port と通信するため、まず torrc で有効にします。
ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1ControlPort は 127.0.0.1 だけで待ち受けます。cookie 認証では、プログラムがコマンドを実行する前に Secret ファイルを読み取る必要があります。Tor はその cookie を /run/tor/control.authcookie に debian-tor ユーザーとして mode 600 で書き込むため、他のユーザーは読み取れません。CookieAuthFileGroupReadable 1 はグループにも読み取りを許可します。これにより、自分のアカウントで sudo なしで nyx を実行できます。
sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@defaultログアウトしてから再度ログインし、nyx を実行します。新しいグループ設定はログイン時に反映されるため、同じシェルセッションで nyx を実行すると、設定が正しくても cookie ファイルの権限エラーになります。nyx には、リアルタイムの帯域幅、稼働時間、ログストリーム、接続一覧が表示されます。最初の数週間は、帯域幅グラフが RelayBandwidthRate 未満で推移しているかを確認します。
リレーを複数運用する: MyFamily と family key
リレーが 1 台だけの場合は、このセクションを読み飛ばしてください。同じ運用者が 2 台以上のリレーを運用する場合は、互いを宣言する必要があります。これにより、クライアントがあなたのマシンから入り、別のあなたのマシンから出る回路を構築することを防ぎます。そのような回路では、1 人の運用者が通信の両端を確認できてしまいます。
従来の方法は、各リレーの torrc に MyFamily を設定し、他のすべてのリレーのフィンガープリントを列挙することです。
MyFamily AAAAAAAAAA,BBBBBBBB各リレーで他のすべてのリレーを列挙するため、4 台目のリレーを追加する場合は 4 つのファイルを編集します。Tor 0.4.9 では、この方法が family key に置き換えられました。1 つの key を生成して共有します。
tor --keygen-family myfamilyこのコマンドは myfamily.secret_family_key を書き込み、FamilyId 行を表示します。key file をすべてのリレーにコピーし、DataDirectory の keys サブディレクトリ（Debian と Ubuntu では /var/lib/tor/keys）に配置します。.secret_family_key suffix は維持してください。表示された FamilyId 行を各 torrc に追加し、sudo systemctl reload tor@default で reload します。現時点では MyFamily list もそのまま残してください。family certificate をまだ理解しないクライアントは、引き続き従来の list を読み取ります。削除できる時期については、Tor Project から告知されます。
稼働後に問題になること
バージョンが古くなる。 Unattended upgrades によってパッケージは更新されますが、実行中のプロセスは再起動されるまで、起動時に読み込んだバイナリを使い続けます。tor --version の出力を、relay の Relay Search ページに表示されるバージョンと比較します。異なっていれば、ネットワークからはまだ古いバージョンが見えているため、サービスを再起動します。
時刻がずれる。 コンセンサス文書と証明書には有効時間が設定されているため、システム時刻が大きくずれるとマシンはコンセンサスを拒否し、公開を停止します。timedatectl で、システム時刻が同期済みと報告されることを確認します。同期されていない場合は、systemd-timesyncd を有効にするか、chrony をインストールします。
IP アドレスが変わる。 descriptor にはアドレスが含まれるため、クライアントは移動後のアドレスへ接続できません。プロバイダーの移行やアドレス変更の後は、tor を再起動し、セルフテストの行が再び表示されることを監視します。
relay の速度がプランの上限を下回る。 Tor の relay 暗号処理は最新のプロセッサーで効率的に動作します。Tor Project によると、AES-NI をサポートする CPU では、各方向でおよそ 400〜450 Mbit/s です。その上限に達するはるか前に、ポート速度と転送量の上限に制限されます。そのため、上記の accounting セクションのほうがハードウェアより重要です。
FAQ
Tor リレーはどの程度の帯域幅を使用しますか？
許可した分だけ使用し、それ以上は使用しません。RelayBandwidthRate は中継トラフィックを方向ごとに個別に制限するため、1 Mbit/s に設定したリレーは、受信 1 Mbit/s と送信 1 Mbit/s を同時に処理できます。これは、両方向を合計すると、1 日あたり約 21.6 GB、30 日の月では 648 GB に相当します。その帯域幅の下に、ハード月間クォータとして AccountingRule sum を指定した AccountingMax を追加します。
Tor リレーを運用すると abuse complaint を受けますか？
Guard リレーまたは middle リレーは、トラフィックを別の Tor リレーにだけ転送し、ユーザーに代わって Web サイトへ接続することはありません。そのため、Tor 経由で誰かが行ったことに関する苦情は、あなたではなく exit operator に届きます。受け取る可能性があるのは、スキャンや、IP アドレスがリレーとして公開されていることによる、ときどきの IP reputation listing です。Abuse mail と legal notice を受け取るのは exit relay であり、事前にその対応に同意した provider が必要です。どちらの種類を始める場合も、先に provider の利用規約を確認してください。
新しい Tor リレーがトラフィックを受け取らないのはなぜですか？
新しいリレーは、測定されるまで意図的に帯域制限されるためです。最初の 3 日間は、directory authority が公開 weight を 20 KB に制限するため、クライアントがそのリレーを選ぶことはほとんどありません。Bandwidth authority はおよそ 3 日目から測定を開始し、8 日目頃に Guard flag の対象になります。ただし、その時点ではクライアントが middle hop の選択時に Guard を避けるため、トラフィックが再び減少します。最大負荷に達するのはおよそ 68 日目です。ログに "Self-testing indicates your ORPort is reachable from the outside" と表示されることを確認し、そのまま待ってください。
1 TB の転送量上限がある VPS で Tor リレーを運用できますか？
はい。各方向を約 1 Mbit/s にすると、これは RelayBandwidthRate 125 KBytes です。Provider が両方向を計測する場合、月間ではおよそ 648 GB となり、更新とバックアップ用の余裕も残ります。リレーがプランの上限を超えないよう、AccountingRule sum と AccountingStart month 1 00:00 を指定した AccountingMax 400 GBytes を追加して、上限に達したら休止するようにします。Provider が送信方向だけを課金する場合は、帯域幅を 2 倍にできます。
1 つのリレーだけを運用する場合、MyFamily を設定する必要がありますか？
いいえ。Family declaration は、同じ operator が所有する 2 つのリレーを通る circuit をクライアントが構築しないようにするためのものです。リレーが 1 つだけの場合は意味がありません。2 つ目を追加したら設定してください。すべてのリレーの fingerprint を、各リレーの MyFamily 行に記載します。または、Tor 0.4.9 で導入された family key を使用します。これにより、増え続ける一覧ではなく、1 つの FamilyId が配布されます。