端末に合ったオープンソースクライアントを選び、サブスクリプションの追加からルーティング設定まで、設定と接続経路を順に確認しましょう。
設定Q&A
まず、サブスクリプション、クライアント、コアの違いを整理してから、該当する設定を変更しましょう。クライアントに「接続済み」と表示されても、通常はローカルプロキシが起動したことを示すだけです。サイトに接続できるかどうかは、サーバーの設定、アプリのプロキシ方式、DNS、ルーティングが正しく連携しているかによります。以下では、よくある操作を項目ごとに解説します。設定例はXray形式を基準にしているため、他のコアでは実際の設定形式を確認してください。
日常使用まずサブスクリプショングループを作成し、URL全体を貼り付けて更新します。サブスクリプションURLからサーバー一覧を取得しますが、個別サーバーの共有リンクとは異なります。種類を間違えると、更新後に一覧が空になることがあります。保存したら、対象のグループを確認して、使用するサーバーを選んでください。更新に失敗した場合は、URLの有効性、ログインページが返されていないか、クライアントからアクセスできるかを確認します。スクリーンショットを共有する際は、アクセス情報が含まれるサブスクリプションURL全体を隠してください。
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}まず直接接続にしたい宛先を決め、具体的なルールを広い範囲のルールより前に置きます。通常、ルーティングは上から順に照合され、最初に一致したルールで出力先が決まります。直接接続のルールを末尾に追加するだけでは、前にあるプロキシルールが優先される場合があります。例のdirectは、実際に存在する出力先タグに合わせてください。また、コアがgeositeのデータファイルを読み込める必要があります。保存後に設定を再読み込みし、新しい接続を作成してログを確認しましょう。グローバルモードを何度も切り替えるより、どのルールに一致したかを把握すると、設定を保守しやすくなります。
dns / routingまず、ドメイン名をどの環境で名前解決しているかを確認してから、DNSサーバーを選びます。ブラウザー、OS、プロキシコアにはそれぞれ別の名前解決経路がある場合があり、1か所を変更してもすべてのアプリに反映されるとは限りません。ドメイン名では接続できずIPアドレスなら接続できる場合は、ログから名前解決の失敗、意図しない結果、問い合わせ経路の不通を確認してください。ドメイン戦略は、ルーティング時に名前解決を試みるかどうかに関わる設定であり、すべてのDNS問い合わせがプロキシ経由になるわけではありません。設定を一度に複数変更するのではなく、1つずつ変更して関連キャッシュを消去すると、原因を特定しやすくなります。
アプリがシステムプロキシに従わない場合は、TUNの使用を検討します。TUNは仮想ネットワークインターフェースを通じて通信を取り込む仕組みで、ブラウザーがシステムプロキシ設定を参照する仕組みとは異なります。有効にする前に、通常のプロキシ接続が動作することを確認し、クライアントに必要な権限、仮想ネットワークアダプターの対応状況、他のネットワークツールとの競合を調べてください。有効にした後は、ローカルデバイス、LAN上のサービス、DNSに引き続きアクセスできるかをテストします。TUNでサーバー設定の誤りは直せず、すべてのアプリで正常に動作するとも限りません。問題が起きたら、いったん無効にして、動作確認済みの基本接続に戻して原因を調べましょう。
まず端末のネットワークと時刻を確認し、次にサブスクリプションとログを調べます。タイムアウトは、接続が規定時間内に完了しなかったことを示すだけで、原因を特定するものではありません。サブスクリプションを更新し、使用中のサーバーを確認したうえで、アドレス、ポート、通信方式、TLSの設定が一式そろっているかを確認してください。ログに出る名前解決の失敗、接続拒否、ハンドシェイクエラーは、それぞれ異なる段階の問題を示します。状況に応じて対処しましょう。同じネットワーク上の複数端末で同じ問題が起きる場合は、サーバーの状態も確認します。エラー内容を見ずにクライアントを何度も再インストールしても、解決にはつながりません。
まずサブスクリプショングループを作成し、URL全体を貼り付けて更新します。サブスクリプションURLからサーバー一覧を取得しますが、個別サーバーの共有リンクとは異なります。種類を間違えると、更新後に一覧が空になることがあります。保存したら、対象のグループを確認して、使用するサーバーを選んでください。更新に失敗した場合は、URLの有効性、ログインページが返されていないか、クライアントからアクセスできるかを確認します。スクリーンショットを共有する際は、アクセス情報が含まれるサブスクリプションURL全体を隠してください。
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}まず直接接続にしたい宛先を決め、具体的なルールを広い範囲のルールより前に置きます。通常、ルーティングは上から順に照合され、最初に一致したルールで出力先が決まります。直接接続のルールを末尾に追加するだけでは、前にあるプロキシルールが優先される場合があります。例のdirectは、実際に存在する出力先タグに合わせてください。また、コアがgeositeのデータファイルを読み込める必要があります。保存後に設定を再読み込みし、新しい接続を作成してログを確認しましょう。グローバルモードを何度も切り替えるより、どのルールに一致したかを把握すると、設定を保守しやすくなります。
まず、ドメイン名をどの環境で名前解決しているかを確認してから、DNSサーバーを選びます。ブラウザー、OS、プロキシコアにはそれぞれ別の名前解決経路がある場合があり、1か所を変更してもすべてのアプリに反映されるとは限りません。ドメイン名では接続できずIPアドレスなら接続できる場合は、ログから名前解決の失敗、意図しない結果、問い合わせ経路の不通を確認してください。ドメイン戦略は、ルーティング時に名前解決を試みるかどうかに関わる設定であり、すべてのDNS問い合わせがプロキシ経由になるわけではありません。設定を一度に複数変更するのではなく、1つずつ変更して関連キャッシュを消去すると、原因を特定しやすくなります。
アプリがシステムプロキシに従わない場合は、TUNの使用を検討します。TUNは仮想ネットワークインターフェースを通じて通信を取り込む仕組みで、ブラウザーがシステムプロキシ設定を参照する仕組みとは異なります。有効にする前に、通常のプロキシ接続が動作することを確認し、クライアントに必要な権限、仮想ネットワークアダプターの対応状況、他のネットワークツールとの競合を調べてください。有効にした後は、ローカルデバイス、LAN上のサービス、DNSに引き続きアクセスできるかをテストします。TUNでサーバー設定の誤りは直せず、すべてのアプリで正常に動作するとも限りません。問題が起きたら、いったん無効にして、動作確認済みの基本接続に戻して原因を調べましょう。
まず端末のネットワークと時刻を確認し、次にサブスクリプションとログを調べます。タイムアウトは、接続が規定時間内に完了しなかったことを示すだけで、原因を特定するものではありません。サブスクリプションを更新し、使用中のサーバーを確認したうえで、アドレス、ポート、通信方式、TLSの設定が一式そろっているかを確認してください。ログに出る名前解決の失敗、接続拒否、ハンドシェイクエラーは、それぞれ異なる段階の問題を示します。状況に応じて対処しましょう。同じネットワーク上の複数端末で同じ問題が起きる場合は、サーバーの状態も確認します。エラー内容を見ずにクライアントを何度も再インストールしても、解決にはつながりません。
例の使い方まず現在正常に動作している設定を記録し、問題ごとに1項目ずつ変更してください。ルーティング画面は設定の関係を示す例であり、そのまま読み込める完全な設定ではありません。出力先タグはクライアントが生成した出力先と一致させ、ルールデータも実際に利用できる必要があります。変更後は新しい接続で確認し、既存の長時間接続が古い経路を使い続けているために、設定が反映されていないと誤解しないようにしましょう。
画面の文言がガイドと異なる場合は、メニューの位置をそのままなぞるのではなく、該当する機能を探してください。デスクトップ版とモバイル版では、サブスクリプション管理、ログの表示場所、プロキシへの接続方法が異なることがあります。初めて使う場合は、まず通常の接続を1つ確立してから、ルーティングやDNSを調整するのがおすすめです。問題が起きたときに、サーバー接続、アプリの通信経路、追加ルールのどこが変わったのかを切り分けやすくなります。
プラットフォームの選び方
デスクトップではv2rayN、Androidではv2rayNGをまず確認しましょう。V2Flyコアとの互換性が必要な場合は、v2flyNGも候補です。クライアントはローカル設定と接続を管理するもので、サブスクリプションやサーバーへの接続情報は別途用意する必要があります。OS、CPUアーキテクチャ、必要なプロトコルを確認してから、該当するプラットフォームのインストーラーを選んでください。ファイル名に見慣れたクライアント名があるだけでインストールしないようにしましょう。
デスクトップではv2rayNが第一候補です。クロスプラットフォーム版と従来のWPF版では画面の技術が異なるため、動作環境もそれぞれ確認してください。初めてインストールする場合は、ダウンロードページの説明を確認し、OSとCPUアーキテクチャに合ったものを選びます。既存の設定を使っている場合は、アップデート前にサブスクリプショングループ、カスタムルーティング、DNS設定をバックアップしてください。
起動後は、まずコアが正常に動作することを確認してから、サブスクリプションを追加し、使用するサーバーを選びます。ブラウザーがシステムプロキシを使わない場合は、ブラウザーの拡張機能、個別のプロキシ設定、クライアントのシステムプロキシの状態を確認してください。ターミナルでは通常、プロキシを別途指定する必要があります。ブラウザーで接続できるからといって、すべてのデスクトップアプリも接続できているとは限りません。
ダウンロードページへまずシステムの「このMacについて」でチップを確認し、Apple SiliconまたはIntelに対応したインストーラーを選びます。v2rayNのクロスプラットフォーム版では、サブスクリプション、サーバー、ルーティングを管理する基本的な手順は共通していますが、システムプロキシの許可、ネットワーク権限、ウィンドウの位置などは他のデスクトップOSと異なる場合があります。
初回起動時にシステムの警告が表示されたら、ダウンロード元とパッケージの種類を確認し、OSが案内するアプリの起動手順に従ってください。システムのセキュリティ機能を一括で無効にするのは避けましょう。接続後はブラウザーと実際に使うアプリの両方で動作を確認します。TUNを使う場合は、クライアントの説明に従って必要な権限を付与し、ローカルネットワークへのアクセスに影響がないか確認してください。
ダウンロードページへAndroidではXrayコアを採用するv2rayNGが第一候補です。V2Flyコアを採用するv2flyNGも選択肢になります。比較的新しい端末の多くではarm64版を選べます。アーキテクチャが分からない場合は、まず端末情報を確認し、必要なら汎用版を検討してください。アーキテクチャはインストール可否に関わり、プロトコルとコアの対応状況は、追加したサーバーを実際に使えるかどうかに関わります。
プロキシを起動すると、通常はシステムからVPN接続の許可を求められます。これはモバイル端末のアプリ通信を取り込む仕組みであり、クライアントが接続先のサーバーを自動で用意するわけではありません。同じ仕組みを使う別のネットワークツールがある場合は、接続の競合に注意してください。バックグラウンドで切断される場合は、省電力設定やバックグラウンド動作の制限も確認し、システムがアプリを停止したのか、サーバー接続に失敗したのかを切り分けましょう。
ダウンロードページへLinuxデスクトップではv2rayNを使用できます。まずディストリビューションのパッケージ形式に合わせてdebまたはrpmを選び、次にx64かarm64かを確認してください。インストールしても、デスクトップ環境が自動でシステムプロキシを使うとは限りません。デスクトップ環境、ブラウザー、ターミナルごとにプロキシ設定の扱いが異なるため、実際に使うソフトウェアで個別に動作を確認しましょう。
クライアントは起動するのにアプリが接続できない場合は、ローカルの待ち受けポート、プロキシの種類、アプリの設定を確認し、その後システムプロキシへの接続を調べてください。プロキシに従わない通信を取り込む必要がある場合に限り、TUNを検討し、クライアントの説明に従って権限を設定します。サーバー上のコマンドライン環境とグラフィカルデスクトップは、インストール方法が異なります。このページでは主にデスクトップ向けクライアントを案内しています。
ダウンロードページへクライアントをインストールすれば接続できますか？有効なサーバー設定またはサブスクリプションも必要です。クライアントは管理と接続に使うツールであり、接続先のサーバーを自動で用意するものではありません。サブスクリプションを利用する場合は、有効期限と対応プロトコルを確認してください。初回接続の手順を見る →
デスクトップとスマートフォンの設定はそのまま移行できますか？一般的な共有リンクはどちらにも追加できる場合がありますが、クライアント固有のバックアップファイル、ルーティングテンプレート、コア設定の互換性は保証されません。移行時はまずサーバーを追加し、ルールは別途確認してください。クライアントごとの違いを見る →
アップデートに失敗したら再インストールが必要ですか？まず、クライアント本体の更新とサブスクリプションの更新を切り分けましょう。前者はインストール環境、後者はURL、ネットワーク、応答形式が原因の場合がよくあります。既存の設定とエラーメッセージを保ったうえで対処してください。ヘルプセンターを見る →
モードを増やせば接続しやすくなりますか？モードによって変わるのは、通信をプロキシに取り込む方法や出力先の選び方です。認証情報や通信方式の誤りが直るわけではありません。まず簡単な経路でサーバーに接続できることを確認し、その後ルールを追加すると、問題の範囲を絞り込みやすくなります。詳細な設定を読む →
エコシステムとメンテナンス
機能の対応状況を理解するには、まずコアとクライアントを区別しましょう。コアはプロトコル、ルーティング、DNSなどのネットワーク処理を担います。クライアントはサブスクリプション、サーバー、設定をまとめ、実行できる形にします。同じ名前の画面でも、内部で使うコアが同じとは限りません。また、同じサーバー設定でも、どのコアでもそのまま動作するとは限りません。
Project Vは、ネットワークプロキシや通信ツールを中心とするオープンソースプロジェクトの背景にあたるもので、V2Rayはその中核ソフトウェアとして広く知られています。開発やメンテナンスの方針が変化するなかで、V2FlyはV2Ray関連の開発を引き継ぎ、Xrayは関連コードを基盤に独自の実装と機能開発を進めています。そのため、検索で使われる「V2Ray」は利用環境全体を指すことも、特定のコアを指すこともあります。設定構文を調べるときは、対象の名称を明確にしましょう。
この関係は、ソフトウェアを1つインストールすればすべての機能を使えるという意味ではありません。GUIクライアントは異なるコアの呼び出し方をまとめられますが、対応プロトコル、通信方式、設定項目はコアごとに異なります。「サーバーを追加できるのに起動しない」場合は、クライアント名だけで互換性を判断せず、実際に選択されているコアと起動ログを確認し、設定項目を認識できていない可能性を調べてください。
まず、サーバーが指定するプロトコルと通信方式に合わせて選び、次に既存設定の移行にかかる手間を考えましょう。両者には共通する概念や歴史的な基盤がありますが、機能の方向性や設定の対応状況は同じではありません。REALITYや特定のflowを含む設定は、使用するコアが対応しているか確認してください。ファイル名を変えたり、別のクライアントにコピーしたりするだけで変換できるとは限りません。
一般の利用者にとっては、抽象的なコアの性能比較よりも、サブスクリプションに含まれる設定一式が重要です。アドレス、ポート、認証情報、通信方式、TLSの設定を正しく組み合わせてください。1項目でも欠けるとハンドシェイクに失敗することがあります。同じ環境で再現できるテストがなければ、接続速度の違いをコア自体の性能に結び付けるのは適切ではありません。まず正常に動く状態を保ち、明確な問題に対して調整すると、より確かな判断ができます。
v2rayNはデスクトップ向けで、サブスクリプション管理、サーバー選択、プロキシ設定などの画面を備えています。v2rayNGはAndroid向けで、Xrayコアを採用しています。v2flyNGもAndroid向けで、V2Flyコアを採用しています。いずれもオープンソースのクライアントプロジェクトですが、このサイトが開発したものではありません。1つのクライアントの機能説明を、他のクライアントにもそのまま当てはめないでください。デスクトップではv2rayNを、モバイルでは必要なプロトコルに応じて選びましょう。
オープンソースとは、コードと関連するライセンス条件を確認・検討できることを意味しますが、接続先のサーバーも同じプロジェクトが提供しているとは限りません。クライアント、コア、サブスクリプションサービスはそれぞれ別の要素です。このサイトでは、これらの関係を理解できるように、ダウンロード先と日本語の操作ガイドをまとめています。サーバーの利用許可、提供状況、利用範囲については、サービス提供元の情報を確認してください。
オープンソースライセンスは、コードの利用、変更、再配布に関する条件を定めています。「コードを閲覧できる」からといって、ライセンスを無視してよいわけではありません。V2Fly関連のコアとXrayの主要コードはMPL 2.0を採用していますが、個別のファイルや依存関係、GUIクライアントについては、それぞれのライセンス表記を確認してください。クライアント、コア、付属コンポーネントでライセンスが異なる場合があります。具体的な利用条件は、配布パッケージに含まれるライセンス表記で確認できます。
更新には複数の種類があります。クライアントの更新は画面や設定生成の処理に、コアの更新はネットワーク処理に、ルールデータの更新はドメインやIPアドレスの分類に、サブスクリプションの更新はサーバー一覧の取得に関わります。これらが同時に更新されるとは限りません。変更前にバックアップを取り、更新後はログを確認して、よく使うアプリで接続をテストしてください。更新後にだけ問題が起きた場合は、どの要素が変わったのか記録しましょう。すべての設定を一度にリセットすると、原因を特定する手掛かりを失うことがあります。
最近の記事
設定のトラブルはまず症状から確認し、仕組みに関する疑問はプロトコルやコアに立ち返って調べましょう。以下の3記事を公開日の新しい順に紹介します。ノードのタイムアウトでは接続経路を順に確認し、システムプロキシの問題ではブラウザーとターミナルを分けて調べます。REALITYとVisionの記事では、サーバー設定の項目を省略できない理由を解説します。手元のログを確認しながら読み、異なるエラーを同じ問題として扱わないようにしてください。
端末の時刻、サブスクリプションの更新、コアのログ、通信方式とTLSの設定、サーバーの状態を順に確認し、v2rayNとv2rayNGでの確認場所も紹介します。
タイムアウトの対処手順を見る →ブラウザーがプロキシを使わない場合は拡張機能やPAC、ターミナルの場合は環境変数の設定が関係することがあります。それぞれ別の経路として確認し、TUNを検討すべき状況も解説します。
アプリごとのプロキシ経路を確認 →TLSを重ねることで生じる暗号化の重複コストを解説し、Visionによるデータ転送の最適化、REALITYによる証明書の扱いの変化、flowや公開鍵の意味と適用条件を紹介します。
プロトコルと通信方式の設定を理解する →