JSON構造の概要：まずオブジェクト階層と処理チェーンを確認
トップレベルオブジェクトの役割
V2Rayの設定ファイルは1つのJSONオブジェクトです。一般的なトップレベル項目には、log、dns、inbounds、outbounds、routing、policy、statsがあります。これらはファイルに記述された順に実行されるのではなく、コアの起動時にそれぞれ対応するモジュールとして解析されます。routingをinboundsより前に書いても、実際の処理順は変わりません。トラフィックの行き先を決めるのは、インバウンドのタグ、ルーティング条件、アウトバウンドのタグ、そしてモジュール間の参照関係です。設定を読むときは、先にすべてのtagを見つけ、参照関係をたどって確認してください。先頭行から末尾まで、記述順だけで読み進めるのは適切ではありません。
inboundsとoutboundsはいずれも配列です。1つのコアで複数のローカルポートを同時に待ち受けたり、複数の出口を用意したりできるためです。routing.rulesも配列で、ルールは通常上から下へ照合されます。一方、dns、log、policyは一般にオブジェクトで、それぞれ名前解決、ログ、セッションポリシーのまとまりを記述します。データ型は正確でなければなりません。配列は角括弧、オブジェクトは波括弧、真偽値はtrueまたはfalseで記述し、引用符付きの文字列にしてはいけません。
最小構成の作り方
次のひな形には、SOCKSインバウンド、直接接続するアウトバウンド、基本的なルーティングルールが1つずつ含まれています。階層を理解するための例であり、リモートサーバー用の完全な設定ではありません。SOCKSリクエストがローカルの待受ポートに入ると、ルーティングモジュールが宛先アドレスを確認し、プライベートアドレスのルールに一致すればdirectアウトバウンドへ渡します。一致しないトラフィックも利用可能なデフォルトアウトバウンドを使うため、本番環境では通常、主要なプロキシ出口を明示的に用意し、直接接続、プロキシ、ブロックの3種類をルールで区別します。
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls"]
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
],
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}JSONの構文エラーと意味エラーを分けて考える
構文エラーは、コアがまだファイルを解釈できない段階で発生します。よくある原因は、末尾のカンマ、引用符の不足、対応しない括弧、標準JSONにコメントを書き込むことです。JSON自体は//や/* */コメントを受け付けません。クライアント画面でコメントを許可している場合は、保存前にクライアント側で追加変換していることが多く、コアが直接読み込むファイルも同じ書式に対応しているとは限りません。意味エラーはJSONとして解析できても、項目の組み合わせが成立しない状態です。たとえば、ルーティングルールが存在しないoutboundTagを参照している、ポートを文字列で記述している、プロトコル名とsettingsの構造が合っていない、といったケースです。
クライアントが設定を生成すると、実行ディレクトリ、リソースファイルの場所、コアの違いに関する項目も追加されます。v2rayNはWindows、macOS、Linuxのデスクトップ設定を管理するのに適しており、v2rayNGとv2flyNGはAndroid環境で異なるコア系統に対応します。グラフィカルクライアントのサブスクリプション項目は、最終的な実行設定そのものではありません。通常、クライアントはノードのパラメータ、ローカルの待受設定、ルーティングルール、DNSオプションを統合してからコアに渡します。そのため、トラブルシューティングではサブスクリプション内の単一ノードだけでなく、クライアントが実際に生成またはエクスポートした実行設定を優先して確認してください。
tagはモジュール間をつなぐ接続点
tagは、設定内部で使う安定した名前と考えられます。インバウンドのタグはルーティングルールのinboundTagから参照され、アウトバウンドのタグはoutboundTagやbalancerTagから参照されます。DNSサーバーもタグを使って特定のアウトバウンドと関連付けられます。タグは大文字と小文字を区別するため、名前を変更したらすべての参照箇所も更新してください。socks-in、proxy、direct、blockのように、意味が明確で短い名前を推奨します。サーバーアドレスや頻繁に変わるメモをタグとして使うのは避けてください。
設定全体を確認するときは、簡単な経路図を作ると便利です。アプリはどのローカルポートに接続するのか、そのポートはどのインバウンドタグに属するのか、ルーティングルールはどのドメイン、IP、ポート、プロトコルで照合するのか、一致後にどのアウトバウンドタグへ渡るのか、そしてアウトバウンドはどのプロトコルとトランスポートを使うのかを整理します。経路上のすべての参照が実在するオブジェクトに解決できれば、構造上の問題の多くを発見できます。以降の章では、この経路に沿って各モジュールを分けて説明します。
inbounds インバウンド：ローカルトラフィックをコアへ入れる方法を定義
待受アドレス、ポート、プロトコル
インバウンドは、ブラウザ、システムプロキシ、LAN内の端末、その他のプログラムから接続を受け取ります。通常、1つのインバウンドオブジェクトには少なくともtag、listen、port、protocol、settingsが含まれます。listenは、どのネットワークインターフェースにバインドするかを決めます。デスクトップクライアントを本機だけで使う場合は、まず127.0.0.1で待ち受けるのが安全です。これにより、LAN内の他の端末からそのポートへ直接アクセスできなくなります。LANに共有する必要がある場合だけ全インターフェースでの待受を検討し、同時にシステムファイアウォール、アクセス制御、SOCKS認証の設定も確認してください。
portは整数で、他のプログラムとの重複を避ける必要があります。v2rayNでよく使われるローカルSOCKS・HTTPポートもクライアント設定から生成されるため、手動設定で特定のポートが必ず空いているとは限りません。コアが「アドレスはすでに使用されています」と表示したら、まず別のクライアントインスタンスが動作していないか確認し、競合するプロセスを終了するか待受ポートを変更します。詳しい手順はv2rayNのポート競合で起動できない場合の対処法をご覧ください。
protocolはインバウンドのプロトコル構造を決めます。ローカルでよく使われるのはsocksとhttpです。SOCKSインバウンドはSOCKS5に対応するプログラムに適しており、設定によってUDPも転送できます。HTTPインバウンドは、HTTPプロキシ設定を使うアプリに適しています。透過プロキシやポート転送は、システムのネットワークスタックと追加権限に関わるため、基本設定で不用意に有効化しないでください。まずはプロキシアドレスを明示設定したアプリを接続できる状態にし、その後に対象範囲を段階的に広げると、トラブルシューティングの経路が明確になります。
SOCKSとHTTPのインバウンドを同時に用意する
{
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls"]
}
},
{
"tag": "http-in",
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http",
"settings": {}
}
]
}2つのインバウンドには異なるポートを割り当てる必要があります。アプリでSOCKS5を選ぶ場合は127.0.0.1:10808、HTTPプロキシを選ぶ場合は127.0.0.1:10809を入力します。OSが入力できるプロキシポートを1つに制限している場合は、クライアントのシステムプロキシモードに従って生成された値を使い、SOCKSポートをHTTPプロキシ専用の入力欄に入れないでください。ポートへのTCP接続が確立できても、ローカルで待ち受けていることしか確認できません。リモートへのアウトバウンド、DNS、ルーティングがすべて正しいとは限りません。
トラフィックスニッフィングの用途と限界
sniffing.enabledを有効にすると、コアは一部の接続についてアプリケーション層の情報から宛先ドメインを復元できます。destOverrideに一般的なhttpとtlsを指定すると、HTTP HostやTLSハンドシェイクのサーバー名で元の宛先を上書きできます。これにより、アプリが先にIPへ名前解決していても、ルーティングモジュールがドメインを取得し、geositeや完全なドメインルールに一致させられる場合があります。
スニッフィングはWebページの内容を復号する機能ではなく、すべての接続からドメインを復元できるわけでもありません。識別可能なホスト情報がないプロトコルでは元の宛先が維持されます。また、宛先アドレスの変更に敏感なアプリでは、有効化後に想定外の接続動作が起きることがあります。特定のアプリだけに問題がある場合は、一時的にスニッフィングを無効にして比較してください。無効化で正常に戻るなら、アウトバウンドプロトコルを疑う前に、ドメインルール、DNSの結果、destOverrideの範囲を確認します。
UDP、認証、LANアクセス
SOCKSインバウンドのudpは、UDP転送リクエストを受け付けるかどうかを決めます。この項目を有効にしても、すべてのアウトバウンドが宛先UDPを自動的にサポートするわけではなく、アプリが必ずSOCKS経由でUDPを送信するわけでもありません。アプリの動作、アウトバウンドの対応能力、ルーティングルールを併せて確認してください。DNSクエリをコア内蔵DNSに任せる場合と、アプリが外部へUDPクエリを直接送る場合では処理経路が異なるため、分けて判断する必要があります。
待受範囲をLANまで広げた後は、アクセス制御を本機だけの環境と同じように扱わないでください。SOCKSではauthとアカウント一覧を使ってユーザー名・パスワード認証を設定できますが、これらの項目をGUIで扱える範囲はクライアントによって異なります。必要なインターフェースとファイアウォールの送信元だけを許可し、モバイル端末が信頼できないネットワークにこのポートを公開しないことを確認するのが安全です。本機だけで使うなら、ループバックアドレスで待ち受けるのが最も簡単で、ポートの誤公開も減らせます。
インバウンドの送信元でルーティングする
複数のインバウンドは異なるプロキシプロトコルに対応するだけでなく、トラフィックの入口を分ける用途にも使えます。たとえば通常のアプリ用にmain-in、直接接続が必要なプログラム用にdirect-inを用意し、ルーティングルールでinboundTagを使って区別します。グローバルモードを頻繁に切り替えるより明確ですが、アプリ側でプロキシポートを個別に指定できることが前提です。この構成では各ポートの用途を設定のそばに記録し、クライアントが設定を再生成した際にタグが上書きされないことも確認してください。
インバウンドのトラブルシューティングは4段階で確認します。プロセスがポートのバインドに成功したか、アプリが正しいプロキシ種別を使っているか、インバウンドが対応するTCPまたはUDPリクエストを受け付けているか、スニッフィングとルーティングが宛先を変更していないか、の順です。前の段階が成立してから次へ進みます。ブラウザに「プロキシサーバーが応答しない」と表示されたら、まず待受とポートを確認します。コアのログに接続記録があるのに宛先へ到達できない場合は、アウトバウンド、ルーティング、DNSの章を確認してください。
outbounds アウトバウンド：プロキシ、直接接続、ブロックの出口を定義
デフォルトアウトバウンドとタグ参照
アウトバウンドオブジェクトは、コアが接続を次のホップまたは最終宛先へ送る方法を記述します。一般的には、主要なプロキシ出口、直接接続出口、ブロック出口の3つを論理的に用意します。プロキシ出口にはVLESS、VMess、Trojanなどを使い、具体的なパラメータはサーバー側の設定に合わせます。直接接続には通常freedom、ブロックには通常blackholeを使います。3つに明確なtagを付け、ルーティングルールのoutboundTagで選択してください。
ルーティングルールに一致しない場合、コアはデフォルトアウトバウンドを使います。コアや設定の構成方法によってデフォルト項目の扱いが異なる場合があるため、重要な振り分けを曖昧な配列位置に依存しないでください。通常のトラフィックには明確なルールを用意し、プライベートアドレス、直接接続が必要なドメイン、ブロック対象もそれぞれ確実なタグへ送るのが保守しやすい方法です。クライアント生成設定では、追加のDNSアウトバウンドやループバックアウトバウンドが挿入されていないかも確認します。
VLESSクライアントのアウトバウンド構造
次の例では、VLESSアウトバウンドの基本的な階層を示します。サーバーアドレスには例示用ドメインを使い、ユーザー識別子も形式を示すためだけのものです。実際の接続にはそのまま使えません。settings.vnextはサーバーの配列で、各サーバーオブジェクトにアドレス、ポート、ユーザー一覧を含めます。ユーザーオブジェクトのidはサーバー側設定と一致させる必要があり、VLESSのencryptionには通常noneを指定します。トランスポート方式、TLS、サーバー名はstreamSettingsに置き、ユーザーオブジェクト内に入れないでください。
{
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "edge.example.com",
"port": 443,
"users": [
{
"id": "11111111-1111-4111-8111-111111111111",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "tls",
"tlsSettings": {
"serverName": "edge.example.com",
"allowInsecure": false
}
}
},
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}addressはコアが実際に接続するサーバーアドレスで、serverNameはTLSハンドシェイクで使う名前です。両者が同じ場合もあれば、構成によって異なる場合もあります。「同じに見せる」ために勝手に統一してはいけません。ポート、トランスポート種別、セキュリティ層、サーバー名、その他の拡張パラメータは、サーバー側と一体で対応させる必要があります。どれか1つでも不一致があると、接続直後に切断される、TLSハンドシェイクに失敗する、長時間待機するといった症状が現れます。
freedomとblackholeの実際の役割
freedomは、コアからローカルネットワークを経由して宛先へ直接アクセスさせます。コアを迂回するわけではありません。トラフィックはインバウンドとルーティングを通過し、アウトバウンド段階でリモートプロキシサーバーへ送られなくなるだけです。プライベートアドレス、ローカル開発サービス、LAN内の端末、ローカル出口が明示的に必要なサイトなどは、通常このアウトバウンドへ送ります。システム自体が宛先を解決またはアクセスできない場合、freedomに送ってもローカルネットワークの問題は自動的に解決しません。
blackholeは、ルールに一致した接続を破棄するために使います。不要なドメイン、IP、プロトコルを明示的にブロックできます。これは「アウトバウンドに一致しない」状態とは異なります。前者は意図的にブロック出口を選んだ状態で、後者は通常、設定や参照の誤りです。トラブルシューティングでは、ログのルーティング結果から区別できます。ブロックルールは具体的に保ち、広すぎるドメインサフィックスやIP範囲で正当なサブドメインや共有アドレス上の別サービスまで影響させないようにしてください。
複数サーバーと負荷分散ポリシー
複数のサーバーを1つのアウトバウンドオブジェクトに入れただけでは、期待どおりの切り替えが自動的に行われるとは限りません。複数の出口が必要なら、通常は出口ごとに独立したタグを作り、ルーティングのロードバランサーまたはクライアントの選択機能で管理します。各サーバーを個別にテストでき、どのルールがどの出口を選んだかも明確になります。グラフィカルクライアントは、選択中のノードに応じてproxyアウトバウンドを動的に生成することがあります。そのため、手動で追加した並列アウトバウンドが次回の設定適用時に再構築される場合があります。
サブスクリプションはノードパラメータの供給元であり、実行設定と同じ階層として扱わないでください。更新後にノードが空になったり項目の解析に失敗したりした場合は、まずサブスクリプション形式とクライアントの互換性を確認し、サブスクリプションの無効化・解析失敗に関する確認項目を参照してください。ノードをインポートできるのに特定の出口だけ接続できない場合は、アドレス、ポート、ユーザー識別子、トランスポート、セキュリティ層を比較し、サブスクリプション全体を何度も更新するのは避けます。
アウトバウンドを段階的に確認する方法
まず、ルーティングが本当に目的のアウトバウンドタグを選んでいるか確認します。次に、サーバーアドレスを解決でき、本機から対応ポートへ到達できるかを確認します。その後、プロトコルの認証項目、最後にstreamSettingsを確認してください。最初からノード交換、DNS無効化、ルーティングモード変更、TLS調整を同時に行うと、どの変更が有効だったのか判断できません。正常に動作する直接接続アウトバウンドを1つ残しておくことも重要です。コア全体の起動、ルーティング選択、単一のプロキシ出口のどこに問題があるかを切り分ける助けになります。
streamSettings：トランスポート方式とセキュリティ層はセットで合わせる
プロトコル層、トランスポート層、セキュリティ層の違い
アウトバウンドのprotocolはVLESS、VMess、Trojanなどのプロキシプロトコルを示し、streamSettings.networkは接続を運ぶトランスポート方式を示します。streamSettings.securityはTLS、REALITY、追加のセキュリティ層なしといった選択を示します。3つは異なる役割を持ちますが、実際の接続ではサーバー側と項目ごとに一致していなければなりません。「VLESSを使う」だけでは接続できません。TCP、WebSocket、gRPCなどのトランスポート方式に加え、サーバー名、パス、サービス名、セキュリティパラメータも必要です。
クライアントは共有リンクやサブスクリプションをインポートすると、各パラメータをコアが認識する項目へ変換します。コアの系統によって、項目名、選択値、拡張機能の一部は完全には一致しません。v2rayNGはXrayコア、v2flyNGはv2flyコアを使う構成が一般的で、v2rayNはデスクトップ向けのコアとノード設定を管理できます。クライアント間で移行する場合は、移行先が実際に使うコアの対応機能を確認してください。内部JSONを一部コピーしただけで、すべての項目が同じように解析されると考えるのは危険です。
TCPとTLSの例
通常のTCPトランスポートでは、networkをtcpに設定します。TLSを有効にする場合はsecurityにtlsを指定し、tlsSettingsを用意します。serverNameは証明書名の確認とハンドシェイクに使うため、サーバー側から指定された値を使用してください。allowInsecureをfalseにすると、通常の証明書検証を行います。trueに変更しても一部の検証を回避するだけで、誤ったポート、誤ったプロトコル、サーバー停止などは直せません。通常の対処として長期間有効にするべきでもありません。
{
"streamSettings": {
"network": "tcp",
"security": "tls",
"tlsSettings": {
"serverName": "edge.example.com",
"allowInsecure": false,
"alpn": ["h2", "http/1.1"]
}
}
}alpnはアプリケーション層プロトコルのネゴシエーションに使います。入力が必要かどうか、値の順序はサーバー側の構成に合わせてください。項目を増やせばよいわけではありません。サーバー側で指定されていない場合は、クライアントの自動ネゴシエーションが適しています。接続に失敗したときも、ALPNの値を無作為に入れ替えるのではなく、ポート、サーバー名、中間プロキシ、サーバー証明書の設定も確認してください。
WebSocketのパスとリクエストヘッダー
WebSocketトランスポートではwsSettingsを使い、一般的な項目はpathです。パスは先頭のスラッシュやクエリ部分を含め、サーバー側と完全に一致させる必要があります。構成によっては特定のHostリクエストヘッダーも必要で、具体的な項目構造はコアの対応方式に依存します。移行時に多い問題は、サーバーアドレスとポートだけをコピーしてパスやホスト名を忘れることです。その場合、TLSには接続できても通常のWebページが返ったり、接続が切断されたりします。
{
"streamSettings": {
"network": "ws",
"security": "tls",
"tlsSettings": {
"serverName": "edge.example.com",
"allowInsecure": false
},
"wsSettings": {
"path": "/vless-connect",
"headers": {
"Host": "edge.example.com"
}
}
}
}アドレス、TLSのサーバー名、HTTP Hostが同じドメインを指す場合もあれば、接続先、証明書検証、リバースプロキシの振り分けを別々に担う場合もあります。サーバー構成を明確に把握している場合だけ変更してください。パスの大文字・小文字は通常意味を持ち、末尾のスラッシュによってルーティング結果が変わることもあります。クライアント画面でこれらが「アドレス」「偽装ドメイン」「パス」などに分かれている場合は、エクスポート後の実際のJSONで対応関係を確認してください。
gRPCとサービス名
gRPCトランスポートでは通常grpcSettingsを使い、重要な項目はserviceNameです。これは通常のWebパスではないため、機械的にスラッシュを付けないでください。構成によっては多重化関連のオプションもありますが、基本的な確認はサービス名、TLSサーバー名、ポートから始めます。サーバーがgRPCを使っているのにクライアントでWebSocketを選んだ場合、双方でTLSを有効にしていても、証明書が正しいだけで互換性が得られるわけではありません。
{
"streamSettings": {
"network": "grpc",
"security": "tls",
"tlsSettings": {
"serverName": "edge.example.com",
"allowInsecure": false
},
"grpcSettings": {
"serviceName": "vless-grpc"
}
}
}REALITY設定の確認順序
REALITYはセキュリティ層の機能で、VLESSと組み合わせて使われることが多いものの、VLESSと同義ではありません。クライアントのパラメータには通常、サーバー名、公 ключ、短いID、フィンガープリントなどが含まれます。具体的な項目は対象コアの対応仕様に従ってください。確認時は、まず現在のコアがこのセキュリティ層に対応しているかを確認し、次にアドレスとポート、続いてサーバー名、公 ключ、短いID、トランスポート方式を順番に比較します。同じアウトバウンドにTLS設定とREALITY設定を混在させている場合、インポートまたは手動統合に問題がある可能性が高いです。
トランスポート層のトラブルシューティングでは、「値を1つずつ推測して試す」方法を避けてください。信頼できる同じサーバー側パラメータを基準に、プロトコル、ネットワーク種別、セキュリティ種別の3つの入口項目を確認してから、対応する設定オブジェクトを確認します。ログに証明書名、ハンドシェイク、サービスパス、プロトコル応答に関するエラーがある場合に限り、その分岐を詳しく調べます。ログがタイムアウトだけを示している場合は、まずDNS解決、宛先ポートへの到達性、誤った出口の選択を除外してください。
多重化とパフォーマンス設定
一部の設定では、アウトバウンドに多重化を設定し、複数の論理接続で基盤接続を共有できます。重複するハンドシェイクを減らせる場合がある一方、サーバーの対応状況、長時間接続の特性、アプリの通信パターンによっては逆効果になることもあります。明確な問題がない場合は、まずクライアントのデフォルト値を使ってください。単一接続は正常なのに同時アクセスで異常が起きる、長時間動作後に停止するといった場合は、他の項目を変えずに多重化を無効にして比較します。パフォーマンス設定は接続が正常になった後に調整するもので、プロトコルやトランスポートの不一致を隠すために使ってはいけません。
routingルーティングルール：順番に照合して出口を選ぶ
ルーティングは出口を決めるだけで、接続能力を作り出すものではない
routingモジュールは、宛先ドメイン、宛先IP、ポート、送信元インバウンド、ネットワーク種別、プロトコルなどの条件に基づき、接続を指定されたアウトバウンドへ渡します。アウトバウンド自体のプロトコルパラメータを変更したり、利用できないサーバーを復旧させたりすることはありません。特定のドメインだけ失敗し他は正常な場合は、ルーティングとDNSを重点的に確認します。すべてのトラフィックが同じプロキシ出口を通れない場合は、まずアウトバウンドの接続能力を確認してください。
rules配列は通常、上から下へ確認され、最初に一致したルールが結果を決めます。そのため、具体的なルールを広範なルールより前に置いてください。たとえば、完全なドメインはプロキシへ送る一方、その親ドメイン全体を直接接続にしている場合、完全なドメインのルールをサフィックスルールより前に置く必要があります。ルールが多い場合は、「ブロック、プライベートアドレス、特別なプロキシ、特別な直接接続、地域分類、フォールバック」のようにグループ分けし、各グループの目的を明確に記録すると管理しやすくなります。
domain、ip、portの記述方法
ドメイン条件には、完全一致、サフィックス、キーワード、正規表現、geosite分類を使えます。マッチング形式ごとにプレフィックスと意味が異なるため、通常の文字列を完全一致として解釈しないでください。IP条件には単一アドレス、CIDRネットワーク、geoip分類を指定できます。ポートは単一の数値または範囲を表す文字列で記述できます。1つのルールに複数種類の条件を指定した場合、通常はすべての種類を満たす必要があります。同じ種類の配列内にある複数の値は、いずれか1つに一致すればよい条件です。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["full:updates.example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"domain": ["domain:example.net", "geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:private", "geoip:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}full:は1つの完全なホスト名だけに一致させたい場合に適し、domain:は通常、そのドメインとサブドメインを対象にします。geosite:は、コアが対応する地域分類のリソースファイルを見つけられることが前提です。geoip:も同様にIPデータリソースを必要とします。リソースファイルの欠落、パスの誤り、クライアント更新後の読み込み失敗があると、起動時にエラーが出たり、ルールが期待どおりに動作しなかったりします。トップページにある「geositeデータを更新」は実際に必要なメンテナンス作業ですが、実行頻度はクライアントの更新機構とルールの要件に応じて決めてください。
domainStrategyがドメインルールとIPルールに与える影響
domainStrategyは、IPルールとの照合に必要な場合にルーティング段階でドメインを解決するかどうかを決めます。AsIsはリクエスト中のドメインを維持し、IPルールのための能動的な解決を行わない傾向があります。IPIfNonMatchは通常、ドメインルールに一致しなかった場合にIPを解決してIPルールを試します。IPOnDemandは、IPルールに関係する名前解決をより早い段階で実行します。具体的な動作は、コアの実装とDNS設定も合わせて理解してください。
戦略を選ぶ前に、ルールの中心が何かを明確にします。主にgeositeと明示的なドメイン一覧を使うなら、不要な名前解決を避けることで経路を簡素化できます。geoipに大きく依存するなら、ルーティング判定に使えるIPをドメインから取得できるようにする必要があります。結果がどこから来るかも重要です。システムDNS、コア内蔵DNS、リモート名前解決では結果が異なり、IP分類の一致結果も変わることがあります。domainStrategyを変更した後は、DNSログとルーティング結果を同時に確認してください。
インバウンド、ネットワーク、プロトコルで振り分ける
inboundTagを使うと、特定の入口から来たトラフィックだけをルールの対象にできます。たとえば直接接続専用の入口を作り、その入口のすべてをdirectへ送れます。networkではTCPとUDPを区別でき、特定のアウトバウンドが一方のネットワーク種別を処理しない場合に便利です。コアによっては特定のアプリケーション層プロトコルも識別できますが、トラフィックから十分な情報をスニッフィングできることが前提です。プロトコル識別に依存するルールは補助的に使い、明確なドメインやポート条件の代わりにしないでください。
{
"type": "field",
"inboundTag": ["direct-in"],
"network": "tcp,udp",
"outboundTag": "direct"
}ルールの競合と優先順位を確認する
ルーティングの競合では、ルール自体は正しくても、広いルールが先に一致して具体的なルールが実行されないケースがよくあります。確認時は対象接続から始め、ドメイン、解決されたIP、ポート、ネットワーク種別、インバウンドタグを記録し、1つ目のルールから順に判定します。期待するルールが存在するかだけでなく、その前に一致可能なルールがないかも確認してください。domain、ip、geositeの整理方法については、カスタムルーティングルールとマッチング優先順位の詳しい解説をご覧ください。
もう1つのよくある問題は、ルールが誤ったタグを参照していることです。クライアントでノードを切り替えると、主要なアウトバウンドタグが再生成される場合があります。手動ルールが古いタグを参照していると、無効になったり起動エラーの原因になったりします。安定させるには、ノードのメモではなく、クライアントが保持する論理タグを使います。クライアントに「LANアドレスをバイパス」の項目がある場合は、プライベートアドレスを直接接続するルールが生成され、適切な優先順位に置かれているか確認してください。重複するルールを手動で追加するのは避けます。
フォールバックルールと保守性
ネットワーク種別だけを指定して主要な出口へ送るルールは、フォールバックとしてよく使われます。大半の接続に一致するため、配列の末尾に置いてください。前半にブロック、プライベートアドレス、特別な振り分けを置き、最後に残りのトラフィックを処理すると、動作を予測しやすくなります。デフォルトアウトバウンドだけに頼ってフォールバックを書かなくても動作する場合はありますが、配列位置とコアの動作を読み手が推測しなければならず、長期的な保守には不向きです。
大規模なルールセットでは、すべてのドメインをメイン設定にばらばらに書くべきではありません。クライアントが対応するルールセット管理機能を使えますが、最終的には生成されたJSONが正しいリソースを参照しているか確認してください。ルールデータを更新した後に通信動作が突然変わった場合は、サーバーノードを先に変更するのではなく、分類内容、リソース読み込みログ、ルール順を比較します。ルーティングは決定的な照合システムです。トラブルシューティングの要点は、実際にどのルールが一致したかを見つけることです。
DNS設定：名前解決元、ドメイン照合、結果の範囲を制御する
コアDNSとシステムDNSの関係
dnsモジュールは、コア内部で解決が必要なドメインに対してサーバーと照合ルールを提供します。ただし、OS上のすべてのDNSリクエストが自動的にコアへ入るとは限りません。アプリがシステムの名前解決を直接呼び出すか、ドメインをSOCKSへ渡すか、独立したDNSパケットを送るかによって、実際の経路は変わります。設定にdns.serversがあるからといって、ブラウザのすべての名前解決がこれらのサーバーを使うとは判断できません。トラブルシューティングでは、「コアがアウトバウンドのサーバーアドレスを解決する場合」「ルーティングが宛先ドメインを解決する場合」「アプリが自分で解決する場合」を区別してください。
コアDNSの利点は、名前解決の選択とルーティングルールを連携できることです。特定のドメインを指定したDNSサーバーに送り、その結果をIPルーティングに使うこともできます。また、特定のドメイン群に想定するIP範囲を設定し、条件に合わない応答を受け入れない構成も可能です。完全な設計では、DNSクエリ自体がどの出口を通るか、結果をどの段階で使うか、アプリが最終接続時にもドメインを保持するかを同時に考えます。
servers配列と条件付きサーバー
serversには単純なサーバーアドレスだけでなく、照合条件付きのオブジェクトも指定できます。オブジェクト形式ではdomainsで対象ドメインを指定し、expectIPsで受け入れる結果の範囲を制限できます。次の例では、特定の分類をローカルネットワークからアクセスできるDNSアドレスに送り、その他のドメインを別のDNSサーバーへ送ります。例示用アドレスは構造の説明を目的としたもので、実際の環境では現在のネットワークと出口経路から到達できるDNSサービスを選んでください。
{
"dns": {
"hosts": {
"router.internal.example": "192.168.1.1"
},
"servers": [
{
"address": "223.5.5.5",
"domains": ["geosite:cn"],
"expectIPs": ["geoip:cn"]
},
{
"address": "1.1.1.1",
"domains": ["geosite:geolocation-!cn"]
},
"localhost"
],
"queryStrategy": "UseIP"
}
}domainsの照合方法はドメインルール体系と関係し、参照する分類リソースも読み込めなければなりません。expectIPsは、名前解決結果を特定のネットワークへ書き換えるものではなく、応答が期待する範囲に入るかを判定・選別するためのものです。条件を狭くしすぎると、正しいアドレスでも分類範囲外として拒否され、そのドメインだけ名前解決に失敗することがあります。トラブルシューティングでは、まず単純なサーバー設定で比較し、その後にドメイン条件と結果の制約を段階的に戻してください。
hostsによる静的マッピング
hostsは、特定の名前に静的な対応関係を与えるために使います。固定されたローカルサービス、テスト環境、明示的に上書きしたいレコードに適していますが、大規模で動的なDNSの代わりにはなりません。宛先アドレスが変わっても静的な値は自動更新されず、設定に残った古いマッピングがドメインを長期間誤ったアドレスへ向けることもあります。「1つのドメインだけがいつも古いサーバーへ接続する」問題を確認するときは、hosts、システムのhostsファイル、クライアントのカスタムDNSマッピングの3か所を検索してください。
静的マッピングの名前がルーティングモジュールに渡ることもあります。ルーティング判定が元のドメインを使うのか、解決後のIPを使うのか、そのIPがどの出口に一致するのかを確認してください。ローカルドメインをプライベートアドレスへマッピングする場合は、通常、プライベートアドレスを直接接続するルールも必要です。そうしないと、接続が誤ってプロキシ出口へ送られ、LAN内サービスにアクセスできなくなることがあります。
queryStrategyとアドレスファミリーの選択
queryStrategyは、問い合わせるアドレス種別を制限します。利用可能なアドレスを両方使う、IPv4だけを問い合わせる、IPv6だけを問い合わせるといった目的で使われますが、具体的な値はコアの実装によって異なります。現在のネットワークが実際にどのアドレスファミリーへ接続できるかを基準に選んでください。IPv6アドレスは返るのに安定したIPv6出口がない場合、アプリが到達不能なアドレスを先に試して遅延やタイムアウトが起こることがあります。反対に、IPv4だけに固定するとIPv6のみを提供する宛先を除外します。
アドレスファミリーの問題は、戦略を何度も切り替えるだけで判断しないでください。DNSの応答、システムのルーティングテーブル、コアの接続ログを個別に確認し、最終的にどの種類のアドレスを試しているかを確認します。プロキシサーバーをドメインで指定している場合は、その解決に使うアドレスファミリーもアウトバウンド接続に影響します。Webサイトは正常に解決できるのにサーバーのドメインだけ解決できない場合、障害は別の段階にあります。
DNSクエリが使う出口を決める
DNSサーバーも1つの宛先であり、問い合わせトラフィックにもネットワーク出口が必要です。設定によってはDNSサーバーにタグを付けたり、専用アウトバウンドで処理したりできます。クライアントが専用のDNSルーティングを生成することもあります。設計時は循環依存を避けてください。プロキシサーバーのアドレスを解決するDNSが、まだ確立していないプロキシアウトバウンドに依存すると、起動時に最初の接続を確立できなくなる可能性があります。一般的には、サーバーアドレスの解決に利用可能なローカル経路を用意し、宛先ドメインの問い合わせはルールに応じて直接またはプロキシの出口を選ばせます。
DNSサーバーをIPではなくドメインで指定すると、そのサーバー自体を先に解決する必要があり、依存関係が1段増えます。基本設定では、まず説明可能な経路を確立し、動作確認後に暗号化DNS、条件付きサーバー、複雑な出口の紐付けを導入してください。日本国内外のドメインを分けて解決する方法、servers、domains、expectIPsの組み合わせについては、V2Ray DNS設定詳解をご覧ください。
キャッシュとトラブルシューティングの順序
DNSの結果は、アプリ、OS、クライアント、コアのいずれかにキャッシュされている可能性があります。設定変更直後に同じ宛先へアクセスしても、古い結果が使われることがあります。正しい手順は、設定を保存し、該当するコアを再起動し、必要に応じてテストアプリも終了・再起動してから、新しいログを確認することです。毎回システム全体のネットワーク状態をリセットする必要はありません。まず、どの層が結果をキャッシュしているかを確認してください。コア再起動後も新しい問い合わせ記録がログに出ないなら、アプリがドメイン解決をコアへ渡していない可能性があります。
DNSのトラブルシューティングは、一定の順序で進めます。まずサーバーアドレスへの到達性を確認し、次に条件なしのルールで結果が返ることを確認します。その後domainsを追加し、最後にexpectIPsと出口の紐付けを追加します。各段階で増やす変数は1つだけにしてください。名前解決に成功しても接続できない場合は、ルーティングとアウトバウンドを確認します。すべての接続エラーをDNSのせいにしないでください。
policy、stats、log：セッションポリシー、統計の有効化、診断記録
policyは接続セッションの動作を制御する
policyは、ユーザーレベルとシステムレベルの実行ポリシーを設定します。一般的な項目には、ハンドシェイクの待機時間、接続のアイドル時間、上り・下りの片方向終了後に接続を保持する時間、ユーザートラフィック統計を有効にするかどうかなどがあります。ドメインルーティングを担当したり、トランスポートプロトコルを変更したりするものではありません。デスクトップクライアントでは通常、デフォルトポリシーで十分です。長時間接続の回収、サーバー側のユーザーレベル、統計取得などの明確な要件がある場合だけ調整してください。
ユーザーレベルは、プロトコルのユーザーオブジェクトにあるlevelとpolicy.levelsで対応付けます。ユーザーにレベルを指定しない場合は、通常デフォルトレベルが使われます。レベルはポリシーのインデックスであり、回線品質や権限の評価値ではありません。手動設定でユーザーにlevel: 1を指定しているのに、レベル0しか定義していなければ、想定したポリシーは適用されません。クライアントのノード設定で、サーバーとクライアントが明確にこの仕組みを使う場合を除き、独自にレベルを追加する必要は通常ありません。
{
"policy": {
"levels": {
"0": {
"handshake": 4,
"connIdle": 300,
"uplinkOnly": 2,
"downlinkOnly": 5,
"statsUserUplink": false,
"statsUserDownlink": false
}
},
"system": {
"statsInboundUplink": true,
"statsInboundDownlink": true,
"statsOutboundUplink": true,
"statsOutboundDownlink": true
}
},
"stats": {}
}handshakeは接続確立段階で待機できる時間を制限します。短すぎるとネットワークの揺らぎで正常な接続まで早く終了し、長すぎると応答のない接続がより長くリソースを占有します。connIdleはアイドル状態の接続を処理するための項目です。長時間保持するものの一時的にデータがないアプリでは影響を受けることがあります。uplinkOnlyとdownlinkOnlyは、片方向終了後の接続保持時間を制御します。十分な理由がない限り、「早く解放する」ためにこれらの値を極端に小さくしないでください。
statsオブジェクトと統計設定の関係
空のstatsオブジェクトを書くだけで、すべての統計データが生成されるとは限りません。policy.systemまたはユーザーレベルのポリシーで該当方向の統計スイッチを有効にし、クライアントやAPIから読み取る必要があります。インバウンドとアウトバウンドの統計は、それぞれのタグの総トラフィックを観察するためのものです。ユーザー統計は、プロトコルユーザーとレベルポリシーに関係します。クライアント画面がデータを読み取らないなら、統計機能は無効のままでも構いません。
グラフィカルクライアントに表示される通信量は、コアの統計APIから取得している場合もあれば、クライアント自身が接続を集計している場合もあります。画面に通信量が表示されても、設定内のすべてのstats項目が有効とは限りません。反対に、統計を有効にしても読み取りAPIがなければ、画面に結果が出ないことがあります。トラブルシューティングでは、まずデータが生成される場所を確認し、次に読み取り方法を確認してください。表示層の問題を転送障害と混同しないことが重要です。
logのアクセス記録、エラー記録、レベル
logには通常、アクセスログの場所、エラーログの場所、loglevelが含まれます。ログレベルはトラブルシューティングの必要に応じて調整できます。日常運用では警告レベルにすると出力を抑えられます。設定の参照、DNSの選択、接続ハンドシェイクに問題がある場合だけ、一時的に詳細度を上げてください。再現と記録が終わったら、長期運用に適したレベルへ戻し、ログの増大や不要な情報の混入を防ぎます。
{
"log": {
"access": "access.log",
"error": "error.log",
"loglevel": "warning",
"dnsLog": false
}
}相対ログパスは通常、設定ファイルのあるディレクトリではなく、コアの作業ディレクトリを基準にします。v2rayNなどのクライアントがコアを起動すると、作業ディレクトリはクライアント側で決まることがあります。手動でログファイルを探す前に、実際の実行ディレクトリを確認してください。パスのディレクトリに書き込み権限がないと、コアがログファイルを作成できず、起動自体に失敗する場合もあります。パスの違いを避けるには、まずクライアントのログ表示機能を使いましょう。カスタムパスが必要な場合は、現在のシステムで確実に書き込めるディレクトリを指定します。
アクセスログは接続先と処理結果を記録し、エラーログは名前解決、ハンドシェイク、リソース読み込み、モジュールの異常を記録します。ログには宛先ドメイン、アドレス、ローカル接続情報が含まれる場合があります。トラブルシューティングの内容を共有する前に、問題と無関係な個人設定を削除してください。完全な設定に含まれるユーザー識別子、サーバーパラメータ、サブスクリプション内容も公開環境へそのまま貼り付けないでください。通常はエラー行、関連モジュール、簡略化した項目構造だけで十分です。
DNSログとルーティング診断
コアによっては、dnsLogまたは詳細ログを使ってDNSクエリを確認できます。この項目の有無と具体的な動作は、現在のコアのドキュメントとクライアントが生成した設定を基準にしてください。有効化したら、問い合わせドメイン、選択されたサーバー、返されたアドレス、失敗理由を重点的に確認します。ルーティング診断では、インバウンドタグ、宛先情報、一致したルール、最終的なアウトバウンドを確認します。両方の記録を組み合わせて初めて、「ドメインがあるアドレスへ解決された後、なぜ特定のIPルールでその出口へ振り分けられたのか」を説明できます。
ログでは、後続の連鎖エラーより最初に出たエラーのほうが重要なことが多いです。たとえばリソースファイルの読み込みに失敗すると、大量のgeositeルールが連続して失敗します。ポートのバインドに失敗すると、アプリ側ではプロキシが使えないという通知が次々に出ます。時系列に沿ってコア起動段階の最初の異常を見つけ、後続の内容が単なる結果ではないか判断してください。コアの起動は成功していて特定の宛先へのアクセス時だけ失敗する場合は、1回の接続記録を追跡します。
APIと管理インターフェースの境界
一部の設定では、APIインバウンドを通じてクライアントに統計、ログ、実行制御の機能を提供します。通常はグラフィカルクライアントが自動生成し、ローカルアドレスにバインドします。この種のインバウンドタグ、サービス一覧、ルーティングルールを手動で変更すると、クライアントがコアの状態を読み取れなくなる可能性があります。APIポートを通常のSOCKSやHTTPプロキシポートとして使ったり、LANへ不用意に公開したりしないでください。クライアントがコアを正常に起動できるのにステータス欄だけ更新されない場合は、APIインバウンド、APIアウトバウンドへのルーティングルール、クライアントが想定するポートを比較します。
policy、stats、log、APIはいずれも実行管理層に属します。接続の観察には役立ちますが、インバウンド、ルーティング、DNS、アウトバウンドの経路確認に代わるものではありません。最小構成では、まずトラフィックが正しく通ることを確認し、その後に統計と管理機能を1つずつ有効にします。これにより、管理インターフェースの問題が起きても、「コアが転送できない」のか「クライアントが状態を表示できない」のかを区別できます。
組み合わせ設定とトラブルシューティング：構文テストから単一接続の追跡まで
まず検証可能な完全な経路を作る
組み合わせ設定では、多数のルール、複数の出口、複雑なDNSを含むファイルから始めないでください。まずローカルSOCKSインバウンド、パラメータが完全で既知のプロキシアウトバウンド、直接接続アウトバウンド、少数の明確なルーティングを用意します。コアが起動し、アプリが接続し、2つの出口が個別に動作することを確認してから、ドメイン分類、条件付きDNS、ブロックルール、統計モジュールを追加してください。層を1つ追加するたびにテストすれば、問題が起きたときに直前の変更へ絞り込めます。
グラフィカルクライアント環境では、設定の供給元が3層に分かれることがよくあります。サブスクリプションまたは手動ノードがリモートパラメータを提供し、クライアント設定がローカルポートとシステムプロキシの動作を提供し、ルーティングとDNSのテンプレートが振り分けロジックを提供します。最終的な実行ファイルは、この3層を統合した結果です。ノード詳細が正しいのに実行に失敗する場合は、実際の設定をエクスポートまたは表示し、クライアントがサーバー名、トランスポート方式、アウトバウンドタグを上書きしていないか確認します。コアをアップグレードまたは切り替えた後は、古い項目が現在のコアでも受け入れられるか確認してください。
構文テストと設定テストを実行する
コアには通常、設定をテストするだけで常駐実行しないコマンドがあります。コマンド名と引数の形式はコアプログラムによって異なりますが、一般的な形式は次のとおりです。実行時には、クライアントが実際に呼び出しているコアファイルと設定パスを使ってください。グラフィカルクライアントに「設定を確認」やログ表示機能がある場合は、正しい作業ディレクトリとリソースパスが適用されるため、まずその機能を使うのが安全です。
v2ray test -c config.json
xray run -test -config config.jsonテストに成功しても、JSONを解析でき、基本モジュールを構築できたことしか示しません。リモートサーバーへ到達できることや、すべてのルーティングが想定どおりであることまでは保証しません。テストに失敗した場合は、出力に示された項目パスと最初のエラーから対処します。地理データを読み込めない場合はリソースファイルと作業ディレクトリを確認し、タグが見つからない場合はルーティングの参照を確認します。アドレスが使用中と表示されたらインバウンドポートを確認し、未知の項目と表示されたら現在のコア系統がその設定に対応しているか確認してください。
ローカル構造検証用の組み合わせ例
次の例にはリモートプロキシの認証情報を含めず、直接接続とブロックの出口でモジュール間の関係を示しています。ローカルのインバウンド、DNS、ルーティング、ログの階層を検証するために使えます。実際にプロキシ出口を追加する場合は、サーバーから提供されたプロトコルとトランスポート項目を完全なオブジェクトとして挿入し、フォールバックルールのoutboundTagを対応するプロキシタグへ変更してください。
{
"log": {
"loglevel": "warning"
},
"dns": {
"servers": ["localhost"]
},
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls"]
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
],
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["full:block.example"],
"outboundTag": "block"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "direct"
}
]
}
}症状からトラブルシューティングの入口を選ぶ
| 症状 | 優先して確認する項目 | 次の手順 |
|---|---|---|
| コアを起動できない | JSON構文、未知の項目、リソースパス、ポート競合 | 起動段階で最初に出たエラーを確認する |
| アプリがローカルプロキシに接続できない | 待受アドレス、ポート、プロキシ種別、プロセスの状態 | インバウンドに接続記録が出ているか確認する |
| すべてのプロキシ宛先がタイムアウトする | ルーティング出口、サーバーの名前解決、宛先ポート、トランスポート層 | directとproxyのアウトバウンドを個別にテストする |
| 一部のドメインだけ失敗する | DNS条件、ルーティング順、スニッフィング、静的マッピング | 名前解決結果と一致したルールを記録する |
| LAN内アドレスにアクセスできない | geoip:private、LANバイパス、インバウンドの待受範囲 | privateルールがフォールバックより前にあるか確認する |
| クライアントに状態が表示されない | APIインバウンド、統計スイッチ、管理用ルーティング | 転送障害と表示障害を区別する |
症状を分類する目的は、無関係な変更を減らすことです。コアが起動できないときは、サーバーへ到達できるかどうかはまだ重要ではありません。アプリがローカルポートへ接続できないなら、まずインバウンドを確認し、リモートノードを交換する必要はありません。一部のドメインだけ失敗する場合は、そのドメインと正常なドメインでDNS、ルーティング、スニッフィングにどのような違いがあるかを調べます。各テストには、同じ出口で正常なドメイン、同じドメインをdirectで接続した結果、複雑なルーティングを無効にした同じノードなど、比較対象を1つ含めてください。
設定変更後に行う固定チェックリスト
保存後、まずJSONと設定のテストを行い、構文エラーやモジュール初期化エラーがないことを確認します。次に、すべてのタグ参照を確認します。各outboundTagが存在し、各inboundTagが実在する入口を指し、負荷分散やAPI関連のタグも名前変更されていないことを確認してください。その後、ローカルポートに競合がなく、クライアントが使うプロキシ種別とインバウンドプロトコルが一致していることを確認します。コア起動後は、直接接続ルール、プロキシルール、プライベートアドレスルールを個別にテストし、最後にUDPや特殊なアプリを確認します。
DNSを変更したら、問い合わせ先サーバーと返されたアドレスを追加で記録します。ルーティング変更では実際に一致したルールを記録し、トランスポート層の変更ではサーバー側パラメータと照合します。ポリシー変更では、Webページを1回開くのではなく長時間接続の動作を観察してください。結果をモジュール単位で記録するほうが、「変更後に何となく速くなった」という感覚より確実です。特定のアプリだけで再現する場合は、そのアプリが自分で名前解決するか、SOCKS UDPに対応するか、システムプロキシを無視するか、古い接続を保持していないかも比較します。
クライアント設定と手動設定を共存させる方法
v2rayNはデスクトップ環境で優先的に使える管理クライアントで、画面からサブスクリプション、ノード、ルーティング、DNSを管理できます。v2rayNGとv2flyNGはAndroid向けで、それぞれ異なるコア系統に対応します。インストールやクライアントの選び直しが必要な場合は、インストーラーページをご覧ください。クライアントが実行設定を生成する場合は、カスタム設定、ルーティング設定、DNS設定の入口から変更するのが基本です。一時生成ファイルを直接編集すると、再起動やノード切り替え後に失われることがあります。
JSONを手動で管理する必要がある場合は、安定した設定とクライアントの一時ファイルを分けて保存し、誰がコアを起動するのかを明確にしてください。2つのクライアントに同じポートを同時に待ち受けさせたり、停止したインスタンスをシステムプロキシが指し続けたりしないようにします。サブスクリプション更新はノードの供給元を更新するだけで、カスタムルーティングやDNSが引き続き適合することを保証しません。更新後は統合結果を確認し、特にアウトバウンドタグとトランスポート項目を見直してください。
再現可能なトラブルシューティング記録を作る
有効なトラブルシューティング記録には、発生時刻、クライアントとコアの種類、関連するインバウンドタグ、対象ドメインまたはアドレス、一致したアウトバウンド、最初のエラー情報、今回変更した項目だけを含めます。機密性のある接続パラメータを含む設定全体をコピーする必要はありません。問題を最小構成に縮小すると、構文、コアの互換性、ネットワーク到達性、ルールロジックのどこに原因があるか判断しやすくなります。
基本設定が完了したら、使い方ガイドに戻ってクライアント操作の流れを確認できます。サブスクリプション異常、ルーティングの優先順位、DNSの振り分け、ポート競合については、記事一覧から症状別に続けて確認してください。体系的な設定の目的は項目を増やすことではなく、各入口、照合条件、出口の役割を明確にし、ログと比較テストで動作を説明できるようにすることです。