SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor ・更新日 2026-08-26

TorとVPNはどちらが必要ですか?違いと選び方

TorとVPNは、誰から何を隠したいかで選択が変わります。各中継で見える情報を比較し、名義付きVPSが匿名化ツールにならない理由も説明します。

Tor と VPN のどちらが必要か

Tor と VPN は、どちらも自分が管理していないマシンを経由してネットワークトラフィックを送信しますが、解決する問題は異なります。VPN(仮想プライベートネットワーク)を使うと、信頼する対象がインターネットプロバイダーから 1 社の事業者に移ります。その事業者は、実際のアドレスとアクセスしたすべての宛先を確認できます。Tor では、信頼を異なる運営者が管理する 3 つのリレーに分散します。そのため、1 つのリレーだけでは、利用者が誰で、どこへ接続しているかの両方を把握できません。誰から身元や行き先を隠したいのかを明確にして、選択してください。

隠したい相手が、現在接続しているネットワークの運営者なら、VPN が適しています。相手が Web サイト自体、または 1 社の記録を提出させる権限を持つ者なら、Tor が適しています。このガイドの残りでは、この 2 つの結論の根拠を詳しく説明します。

2 つの設計で 1 つのリクエストを追跡する

通常のリクエストを 1 つ取り上げます。ブラウザーが https://news.example.com を開きます。どちらの構成でも、TLS(transport layer security)がページの内容を保護するため、途中にいる第三者が記事を読むことはできません。重要なのはメタデータです。誰があなたの IP アドレスを知るのか、誰が宛先を知るのか、そして誰がその 2 つの事実を結び付けられるのかが問題になります。プライバシーツールは、その 2 つを切り離すための仕組みです。VPN は、その組み合わせを別の管理者へ移します。Tor は、それを分割します。

VPN を使用したときに各当事者から見える情報

クライアントはすべてのパケットを暗号化し、1 つのエンドポイントへ送信します。そのエンドポイント以降では、パケットは再び通常のネットワークトラフィックになります。

  • ISP(インターネットサービスプロバイダー)からは、利用回線と 1 つの VPN サーバーアドレスの間で交換される暗号化パケットが見えます。通信量とタイミングは分かります。DNS(ドメインネームシステム)クエリもトンネルを通過している限り、宛先ホスト名は分かりません。
  • VPN 事業者からは、一方に実際の IP アドレス、もう一方にすべての宛先アドレスが見えます。時刻とサイズも分かります。この 2 つの情報は同じマシンに到達します。
  • 宛先からは、VPN の出口アドレスと、ブラウザーが送信するすべての識別情報が見えます。

したがって、VPN は匿名性を提供しません。監視者を ISP から VPN プロバイダーへ移すだけです。ローカルネットワークに問題がある場合や、ISP が把握した情報をフィルタリングまたは再販売している場合には、実際の利点があります。しかし、アクセス先のサイトに対してはまったく効果がありません。通信は、利用者を正確に把握し、支払い記録を保持している 1 つの企業からの 1 本のストリームとして、引き続き到着するためです。

「ログを保存しない」という主張が製品の中心ですが、それは利用者側から確認できない唯一の部分です。トンネルが確立していることは確認できます。DNS が漏れていないことも確認できます。しかし、事業者がディスクに何を書き込んでいるかは確認できません。これが受け入れる取引です。利用者が選んだ 1 つの企業が、全体像を保持します。

トンネルをひそかに無効化する漏れを確認します。

resolvectl status
curl -s https://ifconfig.me; echo

ifconfig.me が表示するアドレスは、VPN の出口アドレスである必要があります。デフォルトルートを運ぶリンクに設定された DNS サーバーは、トンネルのリゾルバーである必要があります。192.168.1.1 にローカルルーターが表示されている場合、名前解決の通信はローカルリンクを経由して平文で送信されています。これは、そのルーターへの経路がオンリンクであり、トンネルのデフォルトルートより具体的だからです。通信内容は保護されていますが、アクセス先サイトの一覧は保護されていません。WireGuard トンネルから DNS クエリが漏れる場合の対処で修正方法を説明します。

Tor を使用したときに各当事者に見える情報

Tor は、ディレクトリ権威の少数のセットが公開する、署名済みリストであるコンセンサスから選ばれた 3 つのリレーでサーキットを構築します。クライアントは、リレーごとに 1 層ずつデータを包みます。各リレーは 1 層だけを取り除き、次のホップだけを知って、残りを転送します。この多層構造により、経路上の誰も 2 つの事実を同時に把握できません。

  • ISP には、1 つのガードリレーへの暗号化されたトラフィックが見えます。リレーのアドレスは公開されているため、ISP は Tor を使用していることを判別できます。ただし、どこへ接続しているかは判別できません。
  • ガードリレーには、実際の IP アドレスが見えます。ただし、宛先は見えません。サイト名を含むメッセージの部分は、その後のリレー向けにまだ暗号化されているためです。
  • 中間リレーには、一方にガード、もう一方に exit が見えます。あなたも宛先も見えません。ガードと exit が直接通信しないようにするために存在します。
  • exit リレーには、宛先と、ネットワークから出ていく際のトラフィックが見えます。あなたのアドレスではなく、中間リレーのアドレスが見えます。HTTPS を使用している場合、ホスト名と接続メタデータは把握できますが、ページの内容は把握できません。
  • 宛先には、公開された exit リストに載っている exit リレーのアドレスと、ブラウザーが送信する情報が見えます。

あなたとサイトを関連付けるには、ガードと exit を同時に把握する必要があります。これが設計を一文で表したものです。そのため、クライアントは起動するたびに新しいガードを選ぶのではなく、同じガードを数か月間使い続けます。入口を常に変更すると、悪意のあるリレーがガードになる機会を繰り返し与えることになるためです。

サーキットは永続的ではありません。新しい接続はおよそ 10 分ごとに新しいサーキットへ移行します。一方、すでに開いているストリームは、開始時に使用したサーキットに残ります。長時間のダウンロードと、15 分後に開いたタブは、通常、異なる exit から接続します。

リレーが他のリレーを知ることなく 3 つのホップを構築する方法

クライアントは、リレーの一覧をガードに渡しません。まずガードと鍵をネゴシエートし、次にガードを 経由して、中間リレーまでサーキットを延長する要求を送信します。その後、そのホップを経由して、exit まで延長する追加の要求を送信します。各リレーには、次に通信する必要がある隣接リレーについてのみ通知されます。また、各ホップには固有の鍵があり、他のホップからは見えません。これにより、中間リレーは検査だけで exit の役割を知ることができません。また、処理したすべてを記録するリレーであっても、記録するのは 1 つの断片だけです。

インストールして経路を確認します。

sudo apt update && sudo apt install -y tor
systemctl status tor@default
journalctl -u tor@default -n 20
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

ログには Bootstrapped 100% (done): Done が表示されるはずです。curl には {"IsTor":true,"IP":"..."} が、見覚えのないアドレスとともに表示されます。これは現在の exit です。IsTor が false の場合、要求はプロキシを経由していません。Ubuntu のパッケージ版 Tor は最新リリースより遅れている場合があります。上流版を追跡する必要がある場合、Tor Project は独自の apt リポジトリを公開しています。

このコマンドには注意点があります。--socks5 を指定すると、curl 自身がホスト名を解決し、解決結果のアドレスをプロキシ経由で送信します。そのため、通常のリゾルバーにはアクセスしたすべての名前が伝わります。--socks5-hostname を指定すると、名前が Tor に送信され、exit が解決します。同じトンネルでも、情報漏えいの内容はまったく異なります。Tor Browser と torsocks はこの点を正しく処理します。手動設定したツールでは、正しく処理されないことがよくあります。

Tor が運べるのは TCP ストリームだけです。UDP は運べないため、ping 1.1.1.1 は Tor を経由しません。また、UDP ベースの VPN プロトコルをその内部で実行することもできません。プロキシ設定を無視するプログラムは、通常のアドレスを使い、通常の経路をそのまま使用します。しかも、警告は表示されません。そのため、システム全体で Tor を使用する場合は、環境変数ではなく、別のボックス上の透過プロキシを使います。

実際に信頼が向かう先

VPN は信頼を集中させます。1 社の事業者が、ユーザーの身元、請求情報、通信パターン全体を保持し、ユーザーの保護はログを保存しないという約束に依存します。その約束が守られている間、構成は単純で、高速で、理解しやすいものです。召喚状、侵害、または虚偽によってその約束が破られると、ユーザーのすべての通信に対して、同時に完全な形で破綻します。

Tor は信頼を分散させます。互いをほとんど知らない 3 者が、それぞれ情報の一部を保持します。その一部だけでは、価値はほとんどありません。構成を機能させるために、全員が誠実である必要はありません。各者が十分に独立している必要があります。その代償として、速度が低下し、TCP のみに制限され、一部のリレーがユーザーを監視したい人物によって確実に運用されているネットワークを利用することになります。悪意のあるリレーに対する Tor の答えは、リレー 1 台だけでは決して十分ではないということです。

VPN が適切な場合

  • ホテル、空港、会議場、家主のルーターなど、ローカルネットワークを信頼できない場合。運用者に見えるのは暗号化されたトンネルだけです。
  • 自分のマシンへ接続したい場合、または自分で管理する固定アドレスから通信したい場合。
  • 速度と UDP が必要な場合。ビデオ通話、ゲーム、大容量転送、バックアップなどです。
  • Web サイトからの追加確認を受けない安定したアドレスが必要な場合。Tor の出口は、Web の広い範囲でブロックされるか、CAPTCHA を要求されます。

この一覧は、サブスクリプションを購入するのではなく、VPS 上で自分の VPN を運用する根拠になります。また、自分で構築する WireGuard サーバーを使えば、ログの保存方針を自分で管理する設定ファイルにできます。デバイス間の鍵管理も加えた同じトンネルが必要な場合は、通常の WireGuard と Tailscale の違いを比較してください。tailnet に接続した後は、自分のサービスへ接続することと、そのうち 1 つをインターネットへ公開することは別の判断です。serve はサービスを tailnet 内に限定し、funnel はサービスを公開します。これらは一覧にある用途にはいずれも適しています。ただし、次の一覧の用途には対応しません。

Tor が適した用途

  • 攻撃者に接続先のサイト、または単一の企業に記録の開示を要求できる者が含まれる場合。
  • 回線まで追跡されると自分に不利益が生じる情報を読んだり公開したりする場合。
  • onion service を利用したい場合。通信がネットワーク外に出ず、exit relay を経由せず、サーバーのアドレスも隠されたままになります。
  • ページ表示の遅さ、CAPTCHA、そして時折発生する 403 Forbidden を許容できる場合。

3 つ目の項目にあるサーバー側の仕組みに関心がある場合は、VPS で v3 onion service を実行する方法を参照してください。exit relay を経由せずにサイトへ接続する方法と、通常の情報漏えいによってマシンが公開アドレスと結び付けられる仕組みを説明しています。

9050 番ポートを指定した普段のブラウザーではなく、Tor Browser を使用してください。ブラウザーは保護の半分を担います。次の次のセクションでは、その理由を説明します。

匿名性の点で、借りた VPS が商用 VPN より劣る理由

この点は誤解されがちです。借りた VPS は、名前が記録された契約です。登録時のメールアドレス、カード情報、請求書、サポートチケットは、すべてその IP アドレスとともに、1 社のデータベースに保存されます。IP アドレスとあなたを結び付けるために、何かを侵害する必要はありません。通常の会計処理のためにすでに記録されており、法的な根拠を伴ってプロバイダーに照会できる人なら、誰でも入手できます。

2 つ目の問題は、利用者の多さです。商用 VPN の出口アドレスは、同じ時刻に多くの顧客が共有します。そのため、アドレスだけでは特定の 1 人に結び付きません。一方、VPS のアドレスはあなただけのものです。そこから送信されるすべてのリクエストは、今日も来月もあなたのものです。アドレスも変わらないため、接続先は Cookie がなくても数か月にわたって利用状況のプロファイルを作成できます。

だからといって、セルフホスト VPN が悪いわけではありません。管理していないネットワーク上でトラフィックを暗号化したり、どこからでも自分のサービスに接続したりする用途には非常に有効です。ただし、匿名化ツールではありません。匿名化ツールとして使うことが誤りです。プロバイダーがマシン自体で確認できる情報と確認できない情報を簡潔に説明した記事については、VPS ホスティングの実際の安全性を参照してください。

Tor でも VPN でも解決できないこと

  • ブラウザーのフィンガープリント。ユーザーエージェント、画面サイズ、タイムゾーン、インストール済みフォント、言語、canvas の描画結果が組み合わさり、多くの場合は固有の値になります。この値は、使用する IP アドレスが変わっても追跡に利用されます。Tor Browser は、利用者同士が同じように見えるようにし、ウィンドウサイズも固定された段階で変更することで、この問題に対処します。SOCKS プロキシの背後で通常のブラウザーを使っても、フィンガープリントと Cookie はそのまま残ります。
  • ログイン。氏名を把握しているアカウントにサインインした時点で、ネットワーク層は重要ではなくなります。自宅からのログインと、同じアカウントへの Tor 経由のログインが 1 つずつあれば、両方のセッションを関連付けられます。
  • エンドポイントが記録する情報。入力した内容、購入した商品、検索した内容などです。
  • エンドツーエンドの相関分析。回線と出口ノードを同時に監視できる者は、通信のタイミングとパケット量を照合し、両端を対応付けられます。Tor は、通信の両側を確認できる攻撃者からは防御できないと明記しています。

Tor と VPN は併用できますか?

Tor over VPN では、最初に VPN が接続し、その内部で Tor が動作します。ISP から見えるのは VPN だけになり、guard relay からはあなたのアドレスではなく VPN のアドレスが見えます。一方で、氏名とカード情報を保有する企業を、まさにその情報を避けるよう設計されたシステムの前段に置くことになります。Tor の利用自体が回線上で危険で、ほかに適切な選択肢がない場合に限り、実施する価値があります。

VPN over Tor は、Tor ネットワークから出たトラフィックを VPN アカウントへ送る構成です。設定が難しく、通常はより適していません。そのアカウントには支払い記録が紐づくため、直前まで匿名だったトラフィックに、固定的な身元情報を結び付けることになります。

目的が ISP から Tor の利用だけを隠すことなら、対応策は bridge です。bridge は公開コンセンサスに含まれない入口であり、obfs4 や Snowflake などの pluggable transport と組み合わせることで、トラフィックを識別しにくくします。Tor Browser には両方が組み込まれており、第三者企業に氏名を伝える必要もありません。

FAQ

Tor は無料の VPN にすぎませんか?

いいえ。VPN では、1 社が運用する 1 台のサーバーを経由してネットワークトラフィックを送信します。その会社は実際のアドレスとすべての宛先を確認できるため、ISP を選択したプロバイダーに置き換える仕組みです。Tor では、異なる運用者が管理する 3 つのリレーを経由します。guard は利用者を確認できますがサイトは確認できず、exit はサイトを確認できますが利用者は確認できません。Tor は TCP のみを使用し、速度も明らかに遅く、多くの Web サイトでブロックまたは追加確認を求められます。そのため、VPN の日常的な用途をそのまま置き換えるものではありません。

ISP は Tor を使用していることを確認できますか?

デフォルトでは確認できます。リレーのアドレスは公開コンセンサスに掲載されているため、プロバイダーは既知の guard リレーへの接続を確認できます。ただし、どのサイトにアクセスしたかは確認できません。Tor の使用自体を隠すには、Tor Browser が提供する obfs4 や Snowflake などの pluggable transport を使用します。これらは公開リストにないエントリーポイントを経由して接続します。Tor の前段に VPN を置く方法でも ISP から Tor の使用を隠せますが、その事実は VPN の運用者に伝わります。

自分の VPS で VPN を運用すれば匿名になりますか?

いいえ。サーバーは利用者名義で、利用者のカードを使ってレンタルするため、プロバイダーの請求記録によって、そのアドレスはすでに利用者と結び付いています。プロバイダーへの照会だけで、その記録を確認できます。また、そのアドレスを使用するのは利用者だけなので、そこから出るすべての通信は 1 人の利用者に属し、サーバーを維持する限り追跡可能です。セルフホスト VPN はローカルネットワークに対するプライバシー保護には有効ですが、プロバイダーに照会できる相手に対する匿名性の手段としては不十分です。

Tor を使用すると Web サイトにブロックされたり CAPTCHA が表示されたりするのはなぜですか?

exit リレーのアドレスは公開され、多数の利用者で共有されているためです。いずれかの利用者による不正利用が、借りているアドレスに結び付けられます。コンテンツ配信ネットワークは、そのようなアドレスの評価を低くし、チャレンジ、403 Forbidden、または送信を拒否する登録フォームを返します。利用者側でこれを解消する方法はありません。新しい circuit を使用すれば別の exit になります。その exit の評価がより高い場合があります。

VPN を使用していても DNS クエリは漏えいしますか?

漏えいする可能性があり、よくある問題です。フルトンネルを使用し、トンネルインターフェースに resolver を設定していない場合、クライアントはローカルネットワークから取得した resolver を使い続けます。その resolver への経路は on-link であるため、トンネルのデフォルトルートより優先されます。その結果、DNS クエリは暗号化されずに送信され、その他の通信だけが暗号化されます。resolvectl status を実行し、デフォルトルートを運ぶリンクに表示された DNS サーバーが、ローカルルーターではなくトンネルの resolver であることを確認してください。