INPUT
サブスクリプションをグループにまとめる
サブスクリプションURLをグループに保存してから更新すると、クライアントが設定を読み込み、サーバー一覧を再構築します。複数の提供元をグループごとに管理でき、更新と絞り込みも混在しません。
OSに合うグラフィカルクライアントを選び、サブスクリプションの導入、システムプロキシ、ルーティングを順に設定します。Xray、V2Fly コアとクライアントの関係も解説します。
Xray-core
永久無料
オープンソース
日本語操作ガイド
CONFIGURATION FLOW
クライアントの画面は異なっても、基本操作の順序は共通です。OSに合うプログラムを選び、有効なサブスクリプションを導入し、プロキシの適用範囲を確認してから、ルールで接続ごとのアウトバウンドを決めます。
INPUT
サブスクリプションURLをグループに保存してから更新すると、クライアントが設定を読み込み、サーバー一覧を再構築します。複数の提供元をグループごとに管理でき、更新と絞り込みも混在しません。
CORE
グラフィカルクライアントは導入、選択、状態管理を担い、コアはプロトコル処理、DNS、インバウンド、アウトバウンド、ルール照合を担います。両者の役割は明確に分かれています。
OUTPUT
ルーティングはドメイン、IP、プロセスなどの条件を上から順に照合し、合致した接続を direct、proxy、block のアウトバウンドで処理します。
SUBSCRIPTION
サブスクリプション導入は、WebページのURLをそのままサーバー接続として扱うことではありません。クライアントはまずサブスクリプションURLを保存し、そこから設定内容を取得します。解析が完了して初めて、選択可能なサーバー項目が作成されます。初回はURLの先頭から末尾まで完全か確認し、提供元ごとに適切なグループへ分けてください。保存後に「サブスクリプションを更新」を実行し、一覧が更新されれば導入完了です。以後も同じ入口から更新でき、項目を一つずつ追加し直す必要はありません。
更新後も一覧が空の場合は、まずシステム時刻、ネットワーク接続、サブスクリプションの有効期限を確認し、次にクライアントログのリクエスト結果を確認します。URL、ネットワーク、解析の問題を切り分けて調査できます。
サブスクリプショングループ
└─ デフォルトグループ
├─ サブスクリプションを追加
├─ サブスクリプションを更新
└─ サーバーを絞り込む
URL 構成:
https://example.invalid/sub?token=xxxx
ROUTING
ルーティングが解決するのは「どの種類の接続をどの出口から出すか」です。クライアントはドメインやIPをルール一覧に渡し、コアが並び順に条件を確認して、direct、proxy、block のいずれかを選びます。一般的には、プライベートアドレスや明確なドメインセットを先に処理し、最後にデフォルトルールを置きます。順序を誤ると広範な条件が先に接続を捕捉するため、変更後はルール内容だけでなく位置と対象アウトバウンドも確認してください。
組み込み設定はすぐに始めたい場合に適し、カスタム設定は特定のドメイン、プロセス、ポートごとに方針を固定したい場合に適しています。ルールを追加するたびに関連する接続だけを確認すると、どの条件が結果を変えたかを見つけやすくなります。
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
SYSTEM PROXY
システムプロキシは、ブラウザーやOSのプロキシ設定に従うデスクトップアプリに適しています。「システムプロキシを自動設定」を選ぶと、クライアントがローカルの待受アドレスをシステム設定へ書き込みます。「システムプロキシを解除」ではこの設定を取り消します。アプリごとのプロキシ設定は変更されないため、接続されない場合は、そのアプリがシステム設定を使うか、独自のプロキシアドレスを保存していないかを確認してください。
トラブル対処では、まずクライアントが起動中か確認し、システムプロキシの状態とローカルポートが対応しているかを確認します。クライアント終了前にシステムプロキシを解除すると、停止したローカル待受ポートをシステムが参照し続けるのを防げます。
システムプロキシメニュー
○ システムプロキシを解除
● システムプロキシを自動設定
○ システムプロキシを変更しない
○ PAC モード
ローカル入口:
http://127.0.0.1:10809
PROXY MODE
プロキシモードはアプリの通信をどのようにクライアントへ取り込むかを決め、ルーティングモードは取り込んだ後にどの出口を選ぶかを決めます。両者を1つのスイッチとして扱うべきではありません。「システムプロキシを自動設定」は主にOS設定に従うアプリを取り込みます。PAC モードはスクリプトでローカルプロキシへ送るアドレスを決めます。「システムプロキシを変更しない」は既存のシステム状態を維持し、アプリで手動設定する場合や別の取り込み方式と併用する場合に適しています。
日常利用では、システムプロキシとルールによるルーティングから始めるとよいでしょう。デバッグ時はまず取り込み方式を固定し、その後ルーティングを一項目ずつ調整します。両方を同時に変更すると判断が難しくなり、問題が入口とアウトバウンドのどちらにあるか確認しにくくなります。
入口層
アプリ → システムプロキシ → ローカルインバウンド
方針層
ローカルインバウンド → ルール照合
├─ direct
├─ proxy
└─ block
DNS
DNS 設定はドメインをアドレスへ変換し、その後のIP照合と接続結果に直接影響します。ドメインルールを使う場合は、システムで解決するのかコアに処理させるのかを明確にしてから、適切な問い合わせ先を選びます。名前解決に成功しても接続に問題がある場合は、DNSの応答値、domainStrategy、最終的なルール一致状況を分けて確認してください。ブラウザーの表示だけで判断してはいけません。
複雑な設定では、ドメインセットごとにサーバーを指定し、ルールによって問い合わせを direct または proxy へ送れます。DNSを変更した後は、古い記録が設定変更を隠さないよう、アプリとシステムのキャッシュを消去してから再度リクエストしてください。
{
"dns": {
"servers": [
"localhost",
{
"address": "https+local://1.1.1.1/dns-query",
"domains": ["geosite:geolocation-!cn"]
}
]
}
}
TUN
TUN モードは仮想ネットワークインターフェースでシステムの通信を受け取るため、システムプロキシ設定を読み取らないアプリにも適しています。有効化する前に、クライアントによるネットワークデバイスの作成とルーティングテーブル変更を許可する必要があります。無効化後は関連ルートが復元されたか確認してください。通常のシステムプロキシより適用範囲が広い一方、システム権限、DNS処理、除外ルールへの依存度も高くなります。
初回有効化時は、多数のカスタムルールを同時に追加しないでください。まず基本設定で通信可能なことを確認し、その後にプライベートアドレスの迂回、LANアクセス、アプリ別ルーティングを追加します。接続が途切れた場合は、サーバーを頻繁に切り替えるのではなく、権限、仮想ネットワークインターフェースの状態、ルーティングテーブル、DNSを順に確認してください。
{
"inbounds": [{
"tag": "tun-in",
"protocol": "tun",
"settings": {
"name": "xray-tun",
"mtu": 1500
}
}]
}
GROUPS
サブスクリプショングループは設定の提供元を管理するもので、ルーティングのアウトバウンドとは別です。仕事用、テスト用など用途の異なるサブスクリプションを分けて保存すれば、個別に更新、絞り込み、サーバー選択ができ、同名項目の混在を減らせます。グループ名には提供元や用途を示し、変化する一時的な接続状態を含めないことをおすすめします。グループ構成は安定しているべきだからです。
グループを更新する前に現在の選択範囲を確認し、更新後に地域やキーワードで絞り込みます。グループを削除すると含まれるサーバー項目にも影響するため、現在のアクティブサーバーがそのグループ由来かを確認し、切り替え可能な設定を用意してください。
サブスクリプショングループ
├─ デフォルトグループ
│ └─ 現在使用中
├─ 作業用設定
│ └─ 個別に更新
└─ テスト用設定
└─ キーワードで絞り込み
DIAGNOSIS
接続に失敗した場合は、「サブスクリプション内容—サーバー選択—コアの稼働—ローカルインバウンド—システム取り込み—ルーティングのアウトバウンド—DNS名前解決」の順に確認することをおすすめします。まずクライアントログに設定解析エラーがないことを確認し、次にシステムが通信を正しいローカルポートへ渡しているかを確認します。入口が正常になって初めて、ルール一致やリモート接続の結果を診断材料として扱えます。
一度に変更する変数は1つにします。たとえばサーバーの変更、ルーティング設定の切り替え、TUN の無効化などです。操作ごとのログ変化を記録すれば、一時的なネットワーク変動を設定修正と誤認せず、安定して再現する条件も早く見つけられます。
確認手順
1. サブスクリプションは更新されたか
2. 設定は解析されたか
3. コアは起動しているか
4. ローカルポートは待受中か
5. システムプロキシは有効か
6. ルーティングと DNS は一致しているか
CLIENT DOWNLOADS
デスクトップ環境では v2rayN、Android では v2rayNG と v2flyNG から選べます。ダウンロードページでは、パッケージ形式、プロセッサーアーキテクチャ、システム要件も案内します。
DESKTOP
v2rayN のグラフィカルクライアントを使用し、デスクトップ版と従来の WPF 版から選べます。初回インストール後は、サブスクリプションを導入してからシステムプロキシとルーティングを設定してください。
DESKTOP
デバイスのプロセッサーに合わせて v2rayN の Apple Silicon または Intel パッケージを選びます。初回起動時は、システムの指示に従ってアプリの許可とネットワーク権限を設定してください。
MOBILE
Xray コアを使う v2rayNG を優先し、V2Fly コアが必要な場合は v2flyNG を選べます。近年の大半のデバイスは arm64 に対応しています。確認できない場合は、システムのアーキテクチャ情報を確認してください。
DESKTOP
v2rayN のデスクトップクライアントを使用し、ディストリビューションに合わせて deb または rpm パッケージを選びます。ARM アーキテクチャの場合は、対応する arm64 ビルドも選択してください。
OPEN SOURCE ECOSYSTEM
クライアント、コア、プロトコル、サブスクリプションサービスはそれぞれ異なる階層に属します。概念を分けて理解することで、インストール、設定、接続の問題がどこで起きているかを正確に判断できます。
Project V は、ネットワークプロキシプロトコルと組み合わせ可能な設定を中心に形成されたオープンソース技術エコシステムです。初期には V2Ray という名称がコアプログラムを指す一方、関連するプロトコル、クライアント、設定形式を総称する言葉としても使われていました。プロジェクトの発展に伴い、V2Fly は v2ray-core のコミュニティメンテナンス路線を引き継ぎ、Xray は一般的な設定思想との互換性を保ちながら独自のコアへ発展しました。どちらもインバウンド、アウトバウンド、ルーティング、DNS、トランスポート、ポリシーなどのモジュールを含みますが、具体的な機能、設定項目、更新ペースは異なる場合があります。
グラフィカルクライアントはコアそのものではありません。v2rayN、v2rayNG、v2flyNG はメニュー、サブスクリプション管理、サーバー選択、ログ確認、システム取り込みの入口を提供します。実際のプロトコル接続とルール照合は、クライアントが呼び出すコアが処理します。そのため、画面操作の問題はクライアント設定を確認し、設定解析、プロトコルハンドシェイク、ルーティング動作の問題はコアログも併せて判断してください。
v2rayN は Windows、macOS、Linux のデスクトップ環境向けで、サブスクリプショングループ、システムプロキシ、ルール、TUN 機能を必要とするユーザーに適しています。v2rayNG は Android 向けで、通常は Xray コアと組み合わせて使い、モバイル環境での導入、選択、起動、アプリ取り込みを中心に構成されています。v2flyNG も Android 向けですが、V2Fly コアを採用しており、対応するコアの動作や設定互換性が必要な場面で利用できます。
3つのプログラムはいずれもコミュニティが保守するオープンソースクライアントです。オープンソースではコード、変更履歴、ライセンス条項を確認できますが、各プロジェクトはそれぞれの保守計画に従って更新されます。クライアントとコアでライセンスが異なる場合もあるため、インストールや再配布の際は製品名だけで判断せず、各プロジェクトに付属するライセンス文書を確認してください。
クライアントの更新には通常、画面、システム連携、サブスクリプション処理、コア管理に関する変更が含まれます。一方、コアの更新では、プロトコル実装、トランスポート動作、ルール、DNS、低レイヤーネットワーク処理が変更される可能性があります。両者を同じ日に更新する必要はありません。ダウンロードページでは現在のクライアント導入先を案内し、プログラム内のコア管理機能では呼び出すコアコンポーネントを確認・切り替えできます。
設定の互換性も階層ごとに判断する必要があります。基本的なインバウンド、アウトバウンド、ルーティング構造は似ていても、特定のプロトコルパラメータや拡張機能を異なるコア間でそのまま再利用できるとは限りません。設定を移行する前に元の内容を保存し、最小構成からテストしてください。基本接続を確認してから、DNS、ルーティング、TUN 設定を段階的に追加します。これにより、どの項目が解析失敗や動作差異を引き起こしたかを特定できます。
COMMON QUESTIONS
以下では、クライアント選択、サブスクリプション更新、システムプロキシ、ルールの順序について説明します。より詳しい導入とトラブル対処は、チュートリアル、上級設定ガイド、よくある質問ページにまとめています。
Windows、macOS、Linux では v2rayN から始められます。ダウンロード時にOSとプロセッサーアーキテクチャを確認し、対応するパッケージを選んでください。インストール後は「サブスクリプションを追加—一覧を更新—サーバーを選択—システムプロキシを設定」の順に進め、利用可能な設定がない段階で複雑なルーティングを変更しないようにします。
クライアント比較を見る →URLの追加で完了するのは保存だけで、サブスクリプションの更新も必要です。更新後も空の場合は、URLが完全か、システム時刻が正確か、サブスクリプションが有効か、ログにネットワークリクエストや内容解析のエラーがないかを順に確認してください。原因によって対処が異なるため、クライアントを何度も削除して再インストールすることはおすすめしません。
サブスクリプション導入手順を見る →システムプロキシの影響を受けるのは、OSのプロキシ設定を読み取るアプリだけです。独自のネットワークスタックを使うアプリ、独自のプロキシアドレスを保存するアプリ、TUN モードでの取り込みが必要なアプリもあります。まずブラウザーなど一般的なアプリが正常か確認し、その後対象アプリのネットワーク設定を確認してください。アプリの取り込み問題をサーバー接続問題と取り違えないことが重要です。
システムプロキシのトラブル対処を見る →direct は接続を直接アウトバウンドへ送り、proxy は設定済みのプロキシへ送り、block は接続を拒否します。ルールは通常上から順に確認され、最初に一致した結果が採用されます。ルールを追加する際はマッチ内容だけでなく、広範なデフォルトルールより前に配置されているかも確認してください。
ルーティングの章を読む →LATEST GUIDES
権限設定、サブスクリプショングループ、DNS経路について、再現しやすい操作手順を整理しています。各記事は1つの具体的な問題に焦点を当て、症状から対応する確認手順へ進める構成です。
システムのブロック通知から始め、プライバシーとセキュリティでの許可、ネットワーク拡張機能の承認、権限リクエストを順に解説します。アプリが起動しない場合と、ネットワーク機能の許可が得られていない場合を分けて対処できます。
続きを読む →複数のサブスクリプションを併用する際の提供元の分離、更新間隔、地域キーワードによるサーバー絞り込みを解説し、グループ選択とルーティング設定を明確に対応させます。
続きを読む →DNSリクエストが想定外の経路へ出る原因を説明し、段階的な検出方法を紹介します。dns アウトバウンドや domainStrategy などの設定項目で、名前解決の通信方向を調整する方法も解説します。
続きを読む →