Tor exit nodeの運用ガイドと必要な対応

Tor exit node の役割と、運用者に求められる立場

Tor exit node は、回線上の最後の relay です。接続先への接続を開くマシンであるため、接続先のログに記録されるのはユーザーのアドレスではなく、あなたのサーバーのアドレスです。このガイドの以降の判断は、すべてこの事実に基づきます。exit node のアドレスは、そこを通過するすべての通信の送信元として扱われます。そのため、他の用途には使わないアドレスを、こうした通信の受け入れに同意した provider で使用する必要があります。

exit node の運用は、身元を隠すこととは正反対です。relay は、誰でもダウンロードできる公開ディレクトリに登録されます。連絡先アドレスは ContactInfo の項目としてそのディレクトリに掲載され、reverse DNS（domain name system）名によってそのサーバーの役割が示されます。port 80 では同じ内容を示すページを提供し、abuse メールにも自分の名前で自分自身が対応します。この仕組みでは、exit operator ほど身元が明確になる立場はありません。それが役割であり、だからこそこの仕組みが機能します。

私たちは実際にこれらを運用しています。SSD Nodes は、自由な表現への貢献として複数の国で exit relay を運用しています。exit traffic の受け入れに意図的に同意した provider からこれらのマシンを借りており、私たちはそれらの provider ではありません。これは意図した構成です。次のセクションで、その理由を説明します。

出口リレーを配置すべき場所と、配置すべきでない場所

出口リレーは汎用 VPS（virtual private server）に配置すべきではありません。これは当社の VPS も例外ではありません。汎用ネットワークでは、隣接するアドレス上で、互いに無関係な数千の顧客向けに Web サイト、メール、バックアップ、コントロールパネルを運用しています。出口トラフィックが発生すると、そのうちの 1 つのアドレスがスキャン報告やスパムブロックリストに登録され、影響が近隣の顧客にも及びます。出口リレーを適切にホスティングするプロバイダーは、その用途専用のアドレス空間を確保し、Tor を理解している abuse 対応窓口を整備しています。

そのため、このガイドを書いているホストが伝えているのは、マシンを別の場所で借りるべきだということです。ここが重要な点です。当社は、自社の出口トラフィックを他社に運んでもらうために料金を支払っています。適切に運ぶには、汎用サーバーを販売する事業とは異なる運用が必要だからです。

Tor Project も、より率直な表現で同じことを説明しています。リレーの種類のページでは、出口リレーについて「すべてのリレーの中で法的な露出と責任が最も大きい」と説明し、「自宅から Tor の出口リレーを運用すべきではない」と述べています。自身のプロジェクトを運用する汎用 VPS は、見た目以上に自宅に近い存在です。自分にとって重要なマシンであり、クリーンな状態を維持したいアドレス上にあるからです。

通常の VPS を使用していて、今週ネットワークに貢献したい場合は、その VPS で非出口リレーまたはブリッジを運用してください。これは代替案にすぎないという意味ではありません。別のリスク特性を持つ別の役割であり、ネットワークにはその両方が必要です。非出口リレーは宛先への接続を開始しないため、苦情はほとんど発生しません。Tor のリレー要件では、各方向で最低 10 Mbit/s（megabits per second）、推奨値として 16 Mbit/s（2 MByte/s）を定めています。ブリッジは、検閲ネットワークのユーザー向けに公開一覧へ掲載しない入口です。24/7 の接続性と、ORPort 用および obfs4 用の 2 つの TCP（transmission control protocol）ポートが必要です。そのため、小規模なマシンで実行できるものの中では、最も価値が高い役割です。これら 2 つは、すでに所有しているハードウェアに配置できます。出口リレーは配置すべきではありません。

撤退しやすいプロバイダーはどう見つけますか？

注文する前に、書面で確認し、返信を保存してください。Tor のexit ガイドラインでは、2 段階で確認することを勧めています。まず、Tor exit の設置自体に問題がないかを尋ねます。次に、その exit 用に専用のアドレスまたはアドレス範囲を割り当ててもらえるかを確認します。両方を一度に尋ねると、反射的に断られやすくなります。

次の4つの質問で、プロバイダーが本当にこの用途に対応できるかを判断できます。

• 他の用途には使わない専用の IP アドレスを割り当て、そのアドレスにこちらが指定する reverse DNS レコードを設定できますか？
• abuse メールを受け取るのは誰ですか。また、そのメールを編集せず、報告者のアドレスを残したまま私に転送できますか。私から報告者へ直接返信できる必要があります。
• 最初の苦情が届いた場合、私に転送しますか。それとも、まずそのアドレスを null-route して、後から確認しますか？
• このネットワーク上では、すでにいくつの exit が稼働していますか？Tor のガイドラインは、この点を明確に述べています。「1 つの友好的な ISP に exit を集めすぎても役に立たない」。

最後の質問は、見た目以上に重要です。exit の価値の一部は、ネットワーク上の配置場所で決まります。すでに50個の exit を収容しているネットワークに別の exit を追加しても、新しい場所に同じマシンを設置する場合ほどの効果はありません。Relay Searchでは、どのネットワークがすでに exit を収容しているかを確認できます。契約する前に調べてください。

支払いの前に回答を受け取り、他のサーバーを保持しているアカウントに追加せず、専用のアカウントでマシンを契約してください。VPS ホスティングの安全性は、主に何を何の隣に配置するかで決まります。この原則を最も明確に示す例です。

1 つのアドレスに 1 つの役割

出口リレーのアドレスでは、ほかのサービスを運用してはいけません。Web サイト、メール、VPN、監視ダッシュボード、個人用 SSH (secure shell) ジャンプホストも同様です。このアドレスはブロックリストに登録されるため、同じ場所で動作するほかのサービスも、原因を特定しにくい形で障害が発生し始めます。単一用途のアドレスにしておけば、苦情への回答も簡潔になります。このアドレスは出口リレーであり、それ以外の用途には使っていない、と説明できます。

tor を導入する前に、通常の対策を実施します。パスワードログインを無効にした鍵認証のみの SSH と、公開するポートだけを許可するファイアウォールを設定します。VPS の SSH を強化するでは前者を、ufw ファイアウォールの基本では後者を説明しています。出口リレーが外部に公開するポートは正確に 2 つです。Tor トラフィックを運ぶ ORPort と、出口通知ページ用の port 80 です。それ以外はすべて閉じたままにします。

unattended upgrades を有効にします。古い tor build のままの出口リレーは、そこを経由するすべてのユーザーにとって問題になるためです。

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

ログを追加してはいけません。出口リレーから出ていく平文を取得することは技術的には容易ですが、運用者が決して行ってはいけない行為です。EFF Tor legal FAQでも、運用者にこの行為をしないよう求めています。米国の wiretap law や他地域の同等の法律により、そのトラフィックを調査した運用者が法的責任を問われる可能性があるためです。tor のデフォルトの notice-level logging だけを維持し、それ以上は追加しないでください。

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

ディストリビューションのパッケージは更新が遅れます。セキュリティ修正がリリースされた当日に届くよう、Tor Project 独自のリポジトリを使用します。2026 年 10 月時点で、現在の安定版系列は 0.4.9 です。Tor Project は 2026 年 9 月 1 日を、0.4.8 以前を廃止する目標日に設定しました。この日以降、これらのバージョンのリレーはネットワーク上でまったく動作しなくなります。そのため、古いパッケージは単に更新が遅いだけでなく、動作しません。

sudo apt update
sudo apt install -y apt-transport-https gnupg wget
lsb_release -cs

lsb_release -cs が出力したコードネームで noble を置き換えて、/etc/apt/sources.list.d/tor.sources を記述します。

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg

署名鍵を追加してから、インストールします。

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
tor --version

deb.torproject.org-keyring パッケージは、その鍵を自動的に最新の状態に保ちます。そのため、鍵がロールオーバーする日にリポジトリが機能しなくなることはありません。apt update が同じリポジトリを 2 回設定していると報告する場合、.list ファイルと .sources ファイルの両方にそのリポジトリが記述されています。deb822 の重複ソースエラーでは、その重複を解消する方法を説明しています。

DNS: exit を利用する全員の名前解決を担当します

exit を経由して出ていくすべての回路について、exit が名前解決を実行します。そのため、exit のリゾルバーには他の利用者に属する名前が連続して届きます。これを大規模なパブリックリゾルバーに向けると、その全体を 1 社に渡すことになります。これは、Tor が exit の運用者に避けるよう求めている集中化です。代わりに、サーバー上で検証機能とキャッシュ機能を備えたリゾルバーを実行します。

sudo apt install -y unbound bind9-dnsutils
sudo cp /etc/resolv.conf /etc/resolv.conf.backup
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf
sudo chattr +i /etc/resolv.conf
sudo systemctl enable --now unbound

chattr +i はファイルを変更不可にします。DHCP (dynamic host configuration protocol) クライアントと resolvconf は、それぞれのタイミングで /etc/resolv.conf を書き換えるためです。これを設定しないと、再起動時に名前解決先がプロバイダーのリゾルバーへ戻る可能性があり、変更されても通知されません。Tor の Debian および Ubuntu 向け手順では、クエリ名の最小化も有効にします。これにより、各ネームサーバーには、実際に必要な名前の一部分だけが送信されます。

server:
    qname-minimisation: yes

これを /etc/unbound/unbound.conf.d/ 配下のファイルに記述し、リゾルバーが応答することを確認します。

sudo systemctl restart unbound
dig +short example.com @127.0.0.1

応答にアドレスが含まれていれば、unbound は動作しています。unbound が address already in use で起動に失敗する場合は、別のプロセスが port 53 を使用しています。sudo ss -lntup | grep :53 を実行し、port 53 の所有者を確認します。Ubuntu では、systemd-resolved は 127.0.0.53 で待ち受けるため、127.0.0.1 で待ち受ける unbound と競合しません。

出口リレーの torrc

Debian パッケージは /etc/tor/torrc を読み込みます。これが出口リレーに関係する設定の全体です。

Nickname     exampleExit01
ORPort       443
ExitRelay    1
SocksPort    0
ContactInfo  email:tor[]example.org abuse:abuse[]example.org url:https://example.org ciissversion:3
ReducedExitPolicy 1
Log          notice syslog

ここにある各行はすべて重要なので、1 行ずつ確認してください。

ORPort 443 は、他のリレーが接続するポートです。443 番ポートは、一般的でないポートをブロックする制限の厳しいネットワークでも通過するため、従来の 9001 番ポートより多くの利用者からリレーに接続できます。このホスト上で他のサービスが 443 番ポートを使用しない場合に限り、443 番ポートを割り当てられます。これも専用アドレスを使う理由の 1 つです。

SocksPort 0 は、ローカル SOCKS プロキシを無効にします。リレーが SOCKS プロキシを必要とすることはありません。公開アドレスで SOCKS ポートを待ち受けると、オープンプロキシとなり、数時間以内に発見されて悪用されます。

ExitRelay 1 は、このリレーを出口リレーにする設定です。デフォルトに依存せず、明示的に設定してください。設定ファイルだけで、このマシンの役割が明確になります。

ContactInfo は公開ディレクトリに掲載され、誰でも閲覧できます。ContactInfo Information Sharing Specification の形式で記述してください。ネットワークのツールはこの形式を解析します。また、ciissversion:3 を必ず含めてください。@ の代わりに [] を使用するのは、アドレス収集ツールの速度を抑えるための、この仕様における慣例です。毎日確認するメールボックスを指定してください。ここに不正利用に関するメールが届きます。

ホストで IPv6 が正常に動作している場合は、IPv6 ORPort を追加し、IPv6 による出口接続を有効にしてください。動作していない場合は、両方とも設定しないでください。実際には使用できないアドレスを広告するリレーは、自身の到達性テストに失敗します。

ORPort   [2001:db8::1]:443
IPv6Exit 1

出口ポリシー: 各ポートで許可する接続先

出口ポリシーは、リレーが接続を許可する接続先の一覧です。Tor は上から順に読み取り、最初に一致したルールを適用します。ReducedExitPolicy 1 は、Web、メール送信、チャット、git で使用する約 100 個のポートを選別した一覧です。苦情の大半を招くポートは含まれていません。最初の出口リレーでは、この設定から始めるのが適切です。

名前を覚えておくべきルールが 2 つあります。ExitPolicyRejectPrivate はデフォルトで有効です。出口リレーがプライベートアドレス範囲や自身のアドレスへ接続することを防ぎます。これにより、出口リレーがプロバイダーの内部ネットワークへ接続するよう誘導されるのを防げます。ポート 25（SMTP、simple mail transfer protocol）は拒否されます。この設定は維持してください。許可するとリレーがスパムの送信元になり、数日以内にそのアドレスがブロックリストへ登録されます。

出口リレーを実用的にするには、少なくともポート 80 と 443 を許可する必要があります。Tor の 出口リレーのドキュメントにも、この最小要件が明記されています。プロバイダーが reduced policy より厳しい設定を求める場合でも、Web 専用の出口リレーは十分に意味のある貢献です。

ExitPolicy accept *:80
ExitPolicy accept *:443
ExitPolicy reject *:*

一覧の最後に reject *:* を指定してください。これによりポリシーが単独で完結し、それ以降の設定を継承しません。reduced policy ではポート 22（SSH）も許可されます。ここは通常、ブルートフォース攻撃の報告が最も多いポートです。この種のメールを受け取りたくない場合は、他のルールより前に ExitPolicy reject *:22 を追加してください。6881-6999 のファイル共有用ポートは、著作権侵害の通知が届く主な原因です。reduced policy ではすでに除外されています。

ポリシーを変更しても、リレーが新しい descriptor を公開し、directory に反映されるまではクライアントに届きません。効果を判断する前に、数時間待ってください。

ContactInfo、family key、リレーの登録

exit relay の登録とは、第三者が検証できる名前にリレーを結び付けることです。そのための仕組みは2つあり、連携して機能します。

1つ目は、よく知られたファイルです。自分が管理するドメインで family identity を公開し、その証明の場所を ContactInfo に指定します。

ContactInfo email:tor[]example.org url:https://example.org proof:uri-familyid-ed25519 ciissversion:3

ファイルは https://example.org/.well-known/tor-relay/ed25519-family-id.txt に配置し、family ID を含めます。これで、これらのリレーを運用していると主張する者が、そのドメインも管理していることを誰でも確認できます。これが、単なる連絡先アドレスと検証済みアドレスの違いです。

2つ目は family 自体です。複数のリレーを運用する場合、ネットワークはそれらが同じ運用者に属することを把握する必要があります。これにより、クライアントが自分の2台のマシンを通る回線を構築することを防ぎます。現在の tor では、0.4.9.2-alpha 以降を実行するリレーで、Happy Families と呼ばれる family key を使用します。

tor --keygen-family exampleFamily

このコマンドは exampleFamily.secret_family_key を作成し、FamilyId 行を出力します。秘密鍵ファイルを各リレーの key directory（Debian と Ubuntu では /var/lib/tor/keys）にコピーします。ファイル名の末尾 .secret_family_key は維持してください。出力された FamilyId 行を各 torrc に追加し、tor を reload します。Tor のマニュアルでは、現時点では relay family に FamilyId と、すべてのリレーの fingerprint を列挙する従来の MyFamily オプションの両方を設定することを推奨しています。これにより、古いクライアントも family を認識できます。両方を設定してください。各リレーの fingerprint は /var/lib/tor/fingerprint にあります。

2台目と3台目のマシンでは、運用が重要になります。複数の Linux サーバーを同時に管理することは、ここでも他の環境と同じ課題です。/var/lib/tor/keys をマシンの外部にバックアップしてください。これを失うと、リレーは見知らぬリレーとして再登録され、すべての flag と評価をゼロから再び獲得する必要があります。

tor-relays メーリングリストにも登録してください。運用者に影響する変更は、まずここで告知されます。

逆引き DNS と port 80 の退出通知

リレーがトラフィックを処理する前に、逆引き DNS レコードを設定します。Tor の退出ガイドラインでは、tor-exit-01.example.org のように、そのサーバーが何であるかを示す名前にするよう求めています。理由は実務的なものです。見慣れないアドレスが誰かのログに現れた場合、管理者が最初に実行するのは逆引きです。名前に "tor-exit" が含まれていれば、問い合わせを受ける前に用途を伝えられます。その結果、本来なら届くはずだった苦情の一部を、苦情そのものにせずに済みます。プロバイダーに PTR (pointer) レコードの設定を依頼し、自分の側にも対応する正引きレコードを追加します。

次に、port 80 で同じ内容を文章で示す通知ページを提供します。以前のガイドでは、tor の DirPortFrontPage 設定を使っていました。この設定には DirPort が必要です。DirPort は tor 0.4.6.5 以降、リレーでは非推奨になっています。そのため、代わりに小規模な Web サーバーを使用します。

sudo apt install -y nginx
sudo install -d -m 755 /srv/tor-exit-notice

/srv/tor-exit-notice/index.html を記述します。

<!DOCTYPE html>
<html>
<head><title>This is a Tor exit relay</title></head>
<body>
<h1>This is a Tor exit relay</h1>
<p>Traffic from this address was sent by a user of the Tor network. It did not
come from the operator of this machine, and this machine keeps no record of
who sent it.</p>
<p>Operator: Example Org. Abuse reports: abuse@example.org. Every report gets a
reply from a person.</p>
<p>To check whether this address was a Tor exit at a given date and time:
https://metrics.torproject.org/exonerator.html</p>
</body>
</html>

この server block を /etc/nginx/sites-available/tor-exit-notice に記述します。

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    root /srv/tor-exit-notice;
    index index.html;
    access_log off;
}

有効化し、nginx のデフォルトサイトを削除して、結果を確認します。

sudo ln -sf /etc/nginx/sites-available/tor-exit-notice /etc/nginx/sites-enabled/tor-exit-notice
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx
curl -s http://127.0.0.1/ | head -n 5

nginx -t が syntax is ok と test is successful を報告すれば、ファイルの構文は正しいという意味です。curl には、通知の先頭行が表示されるはずです。nginx のウェルカムページが表示される場合は、デフォルトサイトがまだ有効で、作成した block が使用されていません。

起動し、ログの内容を確認します

sudo systemctl restart tor@default
sudo journalctl -u tor@default -n 50 --no-pager

数分以内に、他のリレーから接続できることを示す行がログに出ます。行の中央には、設定したアドレスとポートが表示されます。

Self-testing indicates your ORPort 203.0.113.10:443 is reachable from the outside. Excellent. Publishing server descriptor.

この行が表示されない場合、ORPort に到達できません。sudo ss -lntp | grep 443 で tor が待ち受けていることを確認し、別のマシンから nc -vz your.address.here 443 でポートをテストします。VPS の前段にあるファイアウォールが通常の原因です。自分で設定したファイアウォールのほか、プロバイダーのコントロールパネルにあるファイアウォールも確認してください。

systemctl is-enabled tor で、再起動後にサービスが復帰することを確認します。enabled が出力されれば正常です。

リレーは起動から約 3 時間後に Relay Search に表示されます。表示名には、設定した nickname が使われます。その後、トラフィックは数日かけて増加します。ネットワークの帯域幅測定でリレーを観測してからでないと、クライアントがそのリレーを十分に重視しないためです。初日にほとんどトラフィックを処理しない新しい exit は正常です。

迷惑行為への対応手順と、実際に届くメール

最初の苦情が届く前に対応手順を作成してください。通常、最初の苦情は最初の 1 週間以内に届きます。こうしたメールの多くは自動生成されています。Tor の exit ガイドラインでは、大規模な exit 運用者である TorServers.net の報告を引用し、苦情のおよそ 80% が自動化されており、残りの大半も定型返信で解決したと説明しています。実際の割合はポリシーによって異なりますが、標準的な返信で大部分に対応できます。

実際に届く内容は次のとおりです。侵入検知システムが生成したスキャンまたは brute-force の報告で、あなたのアドレスとタイムスタンプが記載されています。ポリシーでファイル共有用ポートを許可している場合は、著作権に関する通知も届きます。サイト運営者から、フォーラムやコメントへの spam に関する苦情が届くこともあります。まれに、法執行機関から証拠保全の要請や召喚状が届きます。これは別の種類の案件であり、定型文を使うのではなく弁護士に相談する段階です。

返信は短く、ほぼ毎回同じ内容です。

Hello,

Thank you for the report. The address 203.0.113.10 is a Tor exit relay,
operated by <your name> at <your organisation>. The connection you saw was
made by a user of the Tor network. It did not originate on this machine.

This relay keeps no record of which user made which connection, so I cannot
identify the sender and there are no logs for me to hand over.

You can confirm that this address was a Tor exit at the date and time in
question here: https://metrics.torproject.org/exonerator.html

If you would prefer to stop Tor traffic reaching your service, the current
list of exit addresses is published here:
https://check.torproject.org/torbulkexitlist

I read this mailbox personally and will answer any follow-up.

<your name>

この対応を機能させるには、4 つの習慣が重要です。1 営業日以内に、ContactInfo に記載されたアドレスから、自分の名前で署名して返信します。ユーザーを特定できるような申し出は絶対にしないでください。実際には特定できず、そのように示唆した運用者は後でその約束を破ることになります。すべての返信を 1 つのフォルダーに保存してください。同じインシデントについて 2 通目のメールが届いても、同じ回答を返せます。プロバイダーが停止警告付きで苦情を転送してきた場合は、報告者より先にプロバイダーへ返信します。

これらの返信では、2 つのリンクが中心的な役割を果たします。ExoneraTor は、調査担当者が実際に知りたい問いに答えます。このアドレスは、その時点で Tor の exit だったのか、という問いです。bulk exit list は、現在の exit アドレスを 1 行に 1 つずつ並べた単純な一覧です。Tor をブロックすると決めた相手が、推測ではなく正確にブロックするために利用できます。

帯域幅、コスト、2 台目のリレー

Exit は実際のネットワークトラフィックを転送します。発注前に月間の上限額を決め、使用量が許容量を超えた場合にプロバイダーがどのように課金するかを確認してください。VPS に実際にかかる費用は、表示価格よりも転送量の許容量で決まることが多いためです。Tor では、こちら側の上限を設定できます。

AccountingMax 4 TBytes
AccountingStart month 1 00:00
RelayBandwidthRate 20 MBytes
RelayBandwidthBurst 25 MBytes

AccountingMax は、会計期間中にその転送量へ達すると tor を休止させ、次の期間の開始時に再開します。数値を信頼する前に、最初の月の使用量をプロバイダー側のカウンターと比較してください。両者で同じバイト数をカウントするとは限らないためです。RelayBandwidthRate は持続転送速度に上限を設けます。これにより、アップリンクを利用可能な状態に保ち、プロバイダーへの負担も抑えられます。

2 台目の Exit を追加する場合は、1 台目と同じラックではなく、別のネットワークに配置してください。多様性は Exit が提供する価値の大部分を占めます。同じ場所にある 2 台のマシンは、同時に障害が発生するためです。両方を 1 つのファミリーに所属させ、検証済みの同じ連絡先を公開し、両方から届くメールに返信してください。誰も連絡できない Exit は、匿名の問題として扱われます。運用者が同日中に返信する Exit は、その背後に人がいるサーバーとして扱われます。実際、そのとおりです。

FAQ

既存の VPS で Tor の exit node を運用できますか？

いいえ。この点は厳格に考えてください。exit node には、他の用途で使用していない専用アドレスが必要です。また、exit traffic の転送に事前に同意し、abuse mail を編集せずに転送するプロバイダーを選ぶ必要があります。一般用途の VPS では、当社の VPS も含め、そのアドレスがすでに別の用途で使われており、通常のサービスを運用する顧客と同じネットワーク上にあります。現在使用しているマシンでは、non-exit relay または obfs4 bridge を運用してください。これらは実際に役立ち、苦情もほとんどなく、すでに料金を支払っているマシンだけで運用できます。

Tor の exit relay にはどの程度の abuse mail が届き、誰が受け取りますか？

exit policy によって異なります。ReducedExitPolicy 1 を設定し、port 25 を拒否してファイル共有用のポートを除外すると、届くものの大半は自動スキャンとブルートフォース攻撃の報告です。Tor の exit guidelines では、大規模な exit operator である TorServers.net の事例として、苦情のおよそ 80% が自動生成されたものだったと紹介しています。これは 1 operator の経験であり、ネットワーク全体の数値ではありません。メールは、プロバイダーの abuse desk が転送した先に届きます。そのため、注文前に、報告者のアドレスを保持したまま自分へ転送するか確認してください。同じアドレスを ContactInfo と port 80 の notice page に掲載し、1 営業日以内に返信してください。

実名とメールアドレスを公開する必要がありますか？

はい。ContactInfo は public relay directory に掲載され、誰でもダウンロードできます。reverse DNS name からは、そのマシンが何であるかが示され、port 80 の notice page にも同じ情報が表示されます。この透明性は設計上の要件であり、副次的なものではありません。機能する連絡先を持たない exit は、匿名の迷惑な relay とみなされます。また、連絡先をまったく公開していない exit を除外するクライアントもあります。自分が管理するドメインに proof:uri-familyid-ed25519 と /.well-known/tor-relay/ed25519-family-id.txt ファイルを追加し、連絡先を単に記載するだけでなく検証可能にしてください。

新しい exit relay がほとんど traffic を処理しないのはなぜですか？

まず、journalctl -u tor@default に Self-testing indicates your ORPort で始まり is reachable from the outside. Excellent. で終わる行があることを確認してください。到達性テストに失敗した relay は公開されず、traffic をまったく処理しないためです。その行がある場合、通常は時間が原因です。relay は起動から約 3 時間後に Relay Search に表示されます。クライアントが十分な traffic を送るのは、ネットワークの帯域幅測定でその relay が確認された後です。この測定には数日かかります。さらに、relay が exit として扱われるには、port 80 と port 443 を許可する policy も必要です。