著者 VPSでTorリレーを運用する方法と注意点
Linux VPSでGuardまたはMiddle Torリレーを構築します。torrcの設定は15行、必要なファイアウォールルールは1つ。従量課金を守る帯域幅計算、nyx監視、新規リレーのconsensus反映が遅い理由も解説します。
VPS 上の Tor リレーが行うこと
Tor リレーは、パブリック IP アドレスを持つマシン上で動作し、他の利用者の暗号化されたトラフィックを転送する Tor デーモンです。ディレクトリ権威がそのリレーを公開し、Tor クライアントがそのリレーを経由する回線を構築します。Guard リレーまたは Middle リレーは、トラフィックを別のリレーに渡すだけです。そのため、他人に代わって Web サイトへの接続を開くことはありません。この点が、abuse メールを受け取らず、一般的な VPS に適した貢献となる理由です。
作業は簡単です。1 つのパッケージ、15 行の設定、1 つのファイアウォールルール、1 回の再起動で済みます。このガイドで問題になるのは、その後の部分です。従量課金プランでの帯域幅の計算と、正常に動作している新しいリレーが 1 週間にわたって停止しているように見える理由を説明します。
Guard、middle、bridge、exit のどれにするかを、インストール前に決める
1 つの daemon で、4 つすべての役割を担えます。どの役割になるかは、設定と directory authorities によって決まります。
- Middle relay。Guard から traffic を受け取り、別の relay に転送します。destination site には接続しません。新しい relay はすべて、まずこの役割から始まります。
- Guard relay。基本的には同じ設定で、追加の flag を 1 つ指定します。directory authorities は、十分な期間にわたって高速かつ安定している relay に Guard flag を付与します。自分で選ぶものではありません。運用実績によって取得します。以下の設定が、その条件を満たすための基盤になります。
- Bridge。public directory から意図的に除外し、Tor がブロックされている場所の users に非公開で配布する relay です。4 つの役割の中で最も小さな負担で済みます。低い bandwidth、public listing なしという構成で、規模を小さく始めたい場合の適切な第一歩です。
- Exit relay。最後の hop であり、destination site への connection を確立します。user が行うすべての request は自分の IP address から送信されるため、abuse report や警察からの照会は、その address の所有者に届きます。
exit は、汎用の VPS で運用してはならない唯一の役割です。exit は、こうした mail の受け取りに事前に同意した provider 上でのみ運用してください。専用の IP address と、公開された abuse contact も必要です。通常の hosting 契約では exit が禁止されていることが多く、それを無視した場合、通常は server の停止と IP address の失効につながります。guard または middle relay なら、同じ user traffic を扱いながら、このようなリスクを負わずに済みます。
以下では 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 エラーを表示した場合、dearmor された鍵が 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 はリレー記述子に公開されます。リレー記述子は誰でもダウンロードできる公開文書なので、アドレスは収集されます。2 年後も読み続けるアドレスを使用し、必要なら難読化します。Tor Project があなたのリレーの問題を通知できる経路は、これだけです。
ORPort 9001 は、他のリレーやクライアントが接続するポートです。9001 が一般的です。ポート 443 もよく使われます。一部の制限されたネットワークでは、外向きの 443 だけが許可されるため、そこで待ち受けるリレーはより多くのクライアントから到達可能になります。443 は、サーバー上の他の用途で必要ない場合だけ選びます。
SocksPort 0 は、リレーが使用しないローカル SOCKS プロキシを無効にし、マシン上の待ち受けソケットを 1 つ減らします。ExitRelay 0 は、その意図をファイルに明示します。このリレーはユーザーの代理で宛先に接続しません。後から設定を読む人がデフォルト値から推測する必要もありません。
VPS に IPv6 アドレスがある場合は、ORPort の行をもう 1 つ追加します。Tor は IPv4 と同じ方法で「任意の」IPv6 アドレスに bind できないため、アドレスを角括弧で囲んで明示します。
ORPort 9001
ORPort [2001:db8::1]:90011 GB の VPS では、MaxMemInQueues 512 MB を追加します。Tor は、マシン上で認識したメモリ量からキューの上限を決定します。小規模な共有サーバーでは、この値は使用させたい量を超えることがあります。上限を自分で設定すると、負荷が高いときに Tor はキューに入ったセルを破棄します。リレーはその状態で動作を継続できます。上限を設定しないと、キューが増え続け、最終的に kernel がプロセスを強制終了する可能性があります。
ファイアウォールで ORPort を開放する
受信方向では、ORPort にインターネット上のどこからでも到達できる必要があります。送信方向では、リレーを制限しないでください。リレーは多数の異なるポートで数千台の他のリレーへ接続するため、送信許可リストを設定すると、気付かないうちに機能が大幅に制限されます。
sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose次に、プロバイダー側のネットワークファイアウォールも確認します。多くのコントロールパネルでは、仮想マシンの前段でパケットフィルターが動作しています。そのため、ufw で追加したルールはそこで適用されず、サーバー上ではポートが開いているのに、外部からは閉じている状態になります。ufw を初めて使う場合は、すべての VPS に設定すべき ufw ルールで、デフォルトポリシーとルールの評価順序を確認できます。
プランに合わせて帯域幅を設定する
マニュアルでは、RelayBandwidthRateを独立した token bucket と説明しています。これは「このノードで中継されるトラフィックの平均受信帯域幅を指定した bytes per second に制限し、平均送信帯域幅も同じ値に制限する」ものです。ここは 2 回読んでください。制限は受信と送信に個別に適用されます。1 Mbit/s に設定した relay は、同時に 1 Mbit/s を受信し、1 Mbit/s を送信できます。両方向を計測する provider では、その合計が課金対象になります。
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 行は測定値ではなく算術計算の結果です。relay が両方向で 30 日間ずっとその rate を維持した場合の通信量を示しています。実際の relay は、多くの時間で上限を下回ります。特に最初の数週間はそうです。この表は、予算に収まらない設定を除外するために使い、請求額を gigabyte 単位で予測するためには使わないでください。
各方向が 1 Mbit/s の場合、relay は 1 日に約 21.6 GB を転送します。そのため、30 日の月では、従量課金されるトラフィックが約 648 GB になります。これは 1 TB の上限内に収まり、更新やバックアップ用の余裕も残ります。2 Mbit/s まで増やすと、その月の通信量は 1,296 GB になり、1 TB プランをすでに超えます。最後の行の 20 Mbit/s には月 12,960 GB が必要で、unmetered port で運用する設定です。provider が送信トラフィックだけを課金する場合は、すべての数値を半分にしてください。rate を設定する前に、どちらの方式かを確認してください。2 つの結果には 2 倍の差があります。
次に config を設定します。先に rate limit、次に quota です。
RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00RelayBandwidthBurstは token bucket のサイズです。平均 rate を維持しながら、短時間だけ rate を超える通信を許可します。rate の約 2 倍が妥当な値です。
AccountingRuleは、多くの operator が見落とす行です。デフォルトは maxです。これは quota に対して、2 方向のうち大きい方を計上します。デフォルトでは、AccountingMax 400 GBytesにより受信 400 GB と送信 400 GB が許可されます。両方向を計測する meter では、合計 800 GB です。AccountingRule sumは read と write を 1 つの quota に合算します。これは実際の transfer allowance が計測する内容です。
AccountingStartも記述してください。AccountingMaxだけを単独で記述してはいけません。quota は通信量で、start line は quota をリセットする期間の開始時点です。period のない quota では、relay は再開するきっかけを失ったまま hibernation 状態になります。
Hibernation は大まかな制御です。quota を使い切ると、tor は次のようにログを記録し、work の受け入れを停止します。
Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted次の period が正確に始まった時点でも、relay は復帰しません。Tor は直前の quota を消費した速度を追跡し、新しい interval 内のランダムな時点を選びます。これにより、数千の relay が同じ秒に network へ戻ることを防ぎます。毎月最後の 1 週間に消える relay は、directory authorities が評価する stability を失い続けます。上限に到達しないように RelayBandwidthRateを設定し、請求額を保護する backstop として 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.次の項目を順番に確認します。ufw で ORPort が開いていますか。プロバイダー側の別のネットワークファイアウォールでも開いていますか。そのメッセージに表示されたアドレスは、インターネットから実際にルーティングされるアドレスですか。NAT 構成によるプライベートアドレスではありませんか。別のマシンから nc -vz 203.0.113.10 9001 でポートをテストします。Tor は自動的にセルフテストを繰り返すため、ファイアウォールを修正すれば、手動で操作しなくても検出されます。再起動すれば、すぐにセルフテストが実行されます。
リレーの永続的な識別情報はフィンガープリントです。
sudo cat /var/lib/tor/fingerprintdescriptor の公開から約 3 時間後に、リレーが Relay Search に表示されます。nickname で検索するか、フィンガープリントを貼り付けます。このページには、ネットワークから見たリレーの状態が表示されます。保持しているフラグ、authority が付与する重み、公開しているバージョンを確認できます。
新しい Tor リレーのトラフィックがほとんどないのはなぜですか？
ネットワークによる測定がまだ行われておらず、測定には数週間かかるためです。Tor Project はこの増加過程を4つの段階に分けて説明しています。これを読んでいない運用者は、リレーが壊れていると判断し、設定を変更し始めます。
最初の3日間、リレーは未測定の状態です。リレーは自己テストの結果を報告しますが、directory authorities は公開される重みを20 KBに制限するため、クライアントに選ばれることはほとんどありません。およそ3日目から8日目までは、bandwidth authorities が実際に帯域幅を測定し、重みが増加します。ただし、新しいリレーを最初のホップとして選ぶクライアントはいないため、この期間は middle hop としてのみ使用されます。
およそ8日目になると、リレーは Guard フラグの対象になります。このフラグを取得するとトラフィックが減少するため、誰もが驚きます。クライアントは、Guard はすでに使用中だと判断し、middle hop を選ぶ際に Guard を除外します。そのため、リレーは Guard トラフィックを得る前に middle トラフィックを失います。クライアントが Guard セットを入れ替えるまで補充されず、その切り替えには数週間かかります。およそ68日目には、リレーを削除するクライアントと追加するクライアントの数が均衡し、安定した状態になります。
したがって、現実的な見込みは、3日間は何も起きず、1週間後に変化が現れ、2か月後に本格的な負荷がかかるというものです。設定は1つだけ変更し、その結果を確認するために1週間待ってください。TCP でポート9001を確認する 自ホスト型の Uptime Kuma ステータスページ は、焦りを紛らわせるより有効です。実際に制御できる問い、つまりポートが応答し続けているかどうかに答えられるためです。
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（Debian と Ubuntu では /var/lib/tor/keys）内にある keys サブディレクトリへ配置します。.secret_family_key サフィックスはそのままにしてください。出力された FamilyId 行を各 torrc に追加し、sudo systemctl reload tor@default で reload します。当面は MyFamily のリストも残してください。family certificate をまだ理解しないクライアントは、引き続き従来のリストを読み取ります。削除できるようになった時点で、Tor Project が告知します。
稼働後に発生する問題
バージョンが古くなります。 Unattended upgrades によってパッケージは置き換えられますが、実行中のプロセスは再起動されるまで、起動時に読み込んだバイナリを使い続けます。マシン上の tor --version と、リレーの Relay Search ページに表示されるバージョンを比較します。異なる場合、ネットワークからはまだ古いバージョンが見えているため、サービスを再起動します。
時刻がずれます。 コンセンサス文書と証明書はすべて時刻に依存するため、マシンの時刻が大きくずれるとコンセンサスを拒否し、公開を停止します。timedatectl で、システムクロックが同期済みと報告されることを確認します。同期されていない場合は、systemd-timesyncd を有効にするか、chrony をインストールします。
IP アドレスが変わります。 ディスクリプターにはアドレスが含まれるため、移動後のアドレスにはクライアントが接続できません。プロバイダーの移行やアドレス変更の後は、tor を再起動し、セルフテストの行が再び表示されるか監視します。
リレーの速度がプランの上限を超えます。 Tor のリレー暗号処理は最新のプロセッサー上で効率的です。Tor Project によると、AES-NI 対応 CPU は各方向でおよそ 400～450 Mbit/s に達します。その上限に達するはるか前に、ポート速度と転送量の上限によって制限されます。そのため、上記のアカウンティングに関するセクションは、ハードウェアより重要です。
FAQ
Tor リレーはどの程度の帯域幅を使用しますか？
許可した分だけ使用し、それ以上は使用しません。RelayBandwidthRate は中継トラフィックを方向ごとに個別に制限するため、1 Mbit/s に設定したリレーは、同時に受信 1 Mbit/s、送信 1 Mbit/s のトラフィックを処理できます。これは、双方向を合計すると、1 日あたり約 21.6 GB、30 日の月では 648 GB に相当します。その帯域幅制限の下に、AccountingRule sum を指定した AccountingMax を追加すると、月間クォータをハード制限できます。
Tor リレーを運用すると abuse complaints が届きますか？
guard リレーまたは middle リレーは、トラフィックを他の Tor リレーにのみ転送し、ユーザーに代わって Web サイトへ接続することはありません。そのため、Tor 経由で誰かが行ったことに関する苦情は、あなたではなく exit オペレーターに送られます。リレーのアドレスは公開されているため、スキャンや、まれに IP レピュテーションのリストに登録されることはあります。abuse メールや法的通知を受け取るのは exit リレーであり、事前に対応を引き受けたプロバイダーが必要です。どちらの種類を始める場合も、事前にプロバイダーの規約を確認してください。
新しい Tor リレーにトラフィックが来ないのはなぜですか？
新しいリレーは、測定されるまで意図的に帯域幅を制限されるためです。最初の 3 日間は、directory authority が公開される weight を 20 KB に制限するため、クライアントがそのリレーを選ぶことはほとんどありません。bandwidth authority は約 3 日目から測定を開始し、約 8 日目には Guard フラグの対象になります。その時点でトラフィックが再び減少します。クライアントは middle hop を選ぶ際に guard を避けるためです。約 68 日目に完全な負荷に達します。ログに "Self-testing indicates your ORPort is reachable from the outside" と表示されることを確認し、そのまま待ってください。
1 TB の転送量が許可された VPS で Tor リレーを運用できますか？
はい。各方向を約 1 Mbit/s にすると、RelayBandwidthRate 125 KBytes です。プロバイダーが双方向の転送量を計測する場合、これは月約 648 GB となり、更新とバックアップ用の余裕も残ります。AccountingRule sum と AccountingStart month 1 00:00 を指定した AccountingMax 400 GBytes を追加すると、プランの上限を超える前にリレーを休止できます。プロバイダーが送信方向だけを課金する場合は、帯域幅を 2 倍にできます。
1 台のリレーだけを運用する場合、MyFamily を設定する必要はありますか？
いいえ。Family 宣言は、同じオペレーターが所有する 2 台のリレーを経由してクライアントが回路を構築しないようにするためのものです。リレーが 1 台だけの場合は意味がありません。2 台目を追加したら設定してください。すべてのリレーの MyFamily 行に、すべてのリレーの fingerprint を列挙します。または、Tor 0.4.9 で導入された family key を使用します。これにより、増え続けるリストではなく、1 つの FamilyId が配布されます。