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) には適しません。これは当方の環境にも当てはまります。汎用ネットワークでは、隣接するアドレス上で、互いに関係のない数千の顧客向けに Web サイト、メール、バックアップ、コントロールパネルを運用します。出口トラフィックが発生すると、そのアドレスがスキャン報告やスパムブロックリストに登録され、影響が隣接する顧客にも及びます。出口リレーを適切にホスティングするプロバイダーは、専用に確保したアドレス空間と、Tor を理解している abuse desk を用意しています。

そのため、このガイドを書いているホストが伝えているのは、マシンを別の場所で契約すべきだということです。ここが重要な点です。当方は、自分たちの出口トラフィックを他社に処理してもらうために料金を支払っています。アドレスに出口トラフィックを適切に流すことは、汎用サーバーを販売することとは別の事業だからです。

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

通常の VPS を利用していて、今週ネットワークに貢献したい場合は、その VPS で非出口リレーまたはブリッジを運用してください。これは代替案にすぎないわけではありません。別の役割であり、リスク特性も異なります。ネットワークには両方が必要です。非出口リレーは宛先への接続を開かないため、苦情はほとんど発生しません。また、Tor のガイダンスでは、リストに掲載する価値がある条件として、各方向で少なくとも 2 MByte/s (megabytes per second) の帯域幅を求めています。ブリッジは、検閲下のネットワークにいるユーザー向けの非公開のエントリーポイントです。24/7 の接続性と、開放した TCP (transmission control protocol) ポートが 1 つ必要です。そのため、小規模なマシンで提供できる価値が最も高い役割です。これら 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 年 8 月時点で、現在の安定版系列は 0.4.9 です。

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 で使用する約 70 個のポートをまとめた選択済みの一覧です。苦情の大半を招くポートは除外されています。初めて出口リレーを運用する場合の出発点として適しています。

名前を覚えておくべきルールが 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 に反映されるまでクライアントには適用されません。効果を判断する前に、数時間待ってください。

連絡先情報、family key、リレーの登録

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

1つ目は、well-known ファイルです。管理しているドメイン上で family の識別情報を公開し、その証明を 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 ディレクトリ（Debian と Ubuntu では /var/lib/tor/keys）にコピーします。ファイル名の末尾に .secret_family_key を付けたままにします。出力された FamilyId 行を各リレーの torrc に追加し、tor を reload します。tor のドキュメントでは、プロジェクトが不要になったと告知するまで、すべてのリレーの fingerprint を列挙する従来の MyFamily オプションも設定する必要があると明記されています。そのため、両方を設定してください。各リレーの fingerprint は /var/lib/tor/fingerprint にあります。

2台目と3台目のマシンでは運用面が重要になります。ここでも、複数の Linux サーバーを同時に管理する場合と同じ問題が発生します。/var/lib/tor/keys をマシン外の場所にバックアップしてください。これを失うと、リレーは見知らぬリレーとして復帰し、すべてのフラグと評価をゼロから再び獲得することになります。

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 is reachable from the outside. Excellent.

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

systemctl is-enabled tor で再起動後にサービスが復旧することを確認します。enabled が出力されるはずです。

リレーは起動から約3時間後に Relay Search に表示され、選択したニックネームが使われます。その後、トラフィックは数日かけて増加します。ネットワークの帯域幅測定では、クライアントがリレーを高く評価する前に、そのリレーを観測する必要があるためです。初日にほとんどトラフィックを処理しない新しい exit は正常です。

インシデント対応手順と、実際に届くメール

最初の苦情が届く前に、対応手順を作成してください。通常、最初の苦情は最初の週に届きます。こうしたメールの大半は自動生成です。Tor の出口ノード向けガイドラインによると、自動生成された報告は全体の約 80% を占めます。残りの多くも、定型文で返信すれば解決します。

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

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

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 の出口ノードだったかどうかです。一括出口リスト は、現在の出口アドレスを 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 メールを編集せずにあなたへ転送する provider を選ぶ必要があります。一般用途の VPS では、当社の VPS も含め、そのアドレスがすでに別の用途で使われており、通常のサービスを運用する他の顧客と同じネットワーク環境を共有しています。利用中のマシンでは、non-exit relay または obfs4 bridge を運用してください。これらは実際に役立ち、苦情もほとんど発生せず、すでに料金を支払っているマシンだけで運用できます。

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

exit policy によって異なります。ReducedExitPolicy 1 で port 25 を拒否し、file-sharing 用の port を除外している場合、届くメールの大半は自動スキャンと brute-force に関する報告です。Tor の exit guidelines では、自動送信された報告が全体のおよそ 80% を占めるとされています。メールを受け取るのは、provider の abuse desk が転送する相手です。そのため、注文前に、報告者のアドレスを改変せずに自分へ転送するか確認してください。同じアドレスを ContactInfo と port 80 の notice page に掲載し、1 営業日以内に返信してください。

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

はい。ContactInfo は public relay directory に掲載され、誰でもダウンロードできます。reverse DNS name によってマシンの用途が示され、port 80 の notice page にも同じ情報が表示されます。この透明性は副次的な結果ではなく、設計上の要件です。連絡先が機能していない exit は、匿名の迷惑ノードとして扱われます。また、連絡先を一切公開していない exit を除外する client もあります。自分で管理している domain に proof:uri-familyid-ed25519 と /.well-known/tor-relay/ed25519-family-id.txt file を追加し、連絡先が単に記載されているだけでなく検証できるようにしてください。

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

まず、journalctl -u tor@default に Self-testing indicates your ORPort is reachable from the outside. Excellent. が含まれているか確認してください。reachability test に失敗する relay は公開されず、traffic をまったく転送しないためです。その行がある場合、通常は時間が必要です。relay は起動から約 3 時間後に Relay Search に表示されます。client が実質的な traffic を送るようになるのは、network の bandwidth measurement がその relay を確認してからであり、数日かかります。さらに、relay が exit として扱われるには、port 80 と 443 を許可する policy も必要です。