config.json 設定項目ガイド

JSON構造の概要

V2Rayエコシステムの設定ファイルは、データ処理の流れ全体を定義します。アプリがローカルの待ち受けポートに接続し、inboundsからリクエストをコアに渡します。ルーティングが宛先や送信元に応じてoutboundを選び、outboundが実際の接続を確立します。dnsは内蔵の名前解決機能を提供し、policyは接続の一部の段階に時間制限を設けます。ファイル名は一般にconfig.jsonですが、意味を決めるのは名前ではなくファイルの内容と読み込むコアです。設定を読む前に、XrayとV2Flyのどちらを使うか確認し、そのコアが対応する設定形式と照らし合わせてください。

オブジェクト、配列、フィールドの型

トップレベルはJSONオブジェクトです。inboundsとoutboundsは配列です。同じプロセスで複数の待ち受け口を用意したり、複数の出口を設定したりできるためです。routing、dns、policyはオブジェクトで、それぞれルール、サーバー、ポリシーの対応関係を保持します。フィールド名と文字列には半角のダブルクォートを使い、ポート番号には通常数値、スイッチにはtrueまたはfalseを指定します。数値と文字列は相互に置き換えられません。パス、タグ、プロトコル名も正確に記述してください。

厳密なJSONでは、コメント、末尾のカンマ、全角の引用符は使用できません。コアのツールによっては独自の設定読み込み機能が用意されている場合もありますが、クライアント間で設定を共有するなら厳密なJSONを保ちましょう。例のインデントは読みやすさのためで、実行には影響しません。解析に影響するのは括弧、カンマ、データ型です。JSONパーサーで読み込めても、プロトコルの項目やoutboundの参照、実行環境が正しいとは限りません。起動に失敗したら、まずJSON構文のエラーとコア設定のエラーを切り分け、複数の層を同時に変更しないようにしましょう。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  },
  "dns": {
    "servers": ["localhost"]
  }
}

設定セクション間の参照関係

tagは設定内で使う名前であり、サーバーに送信する認証情報ではありません。ルールのoutboundTagには、実在するoutboundのタグを指定します。inboundTagを使うと、特定の待ち受け口からのリクエストだけをルールの対象にできます。タグは短く安定した英語名にし、各配列内で重複しないようにしてください。outboundのタグを変更する場合は、それを参照するルールもすべて変更します。そうしないと、設定ファイルに不備がないように見えても、接続が意図どおりに振り分けられません。通常、デフォルトのoutboundには配列の先頭の項目が選ばれるため、並び順も設定の動作に関わります。

トップレベルのセクションを記述する順番は、処理順を表すものではありません。dnsをroutingより前に記述しても、すべてのリクエストが内蔵DNSを先に通るわけではありません。一方、ルールを配列の先頭に移すと、実際にマッチする条件が変わることがあります。設定を読む際は、オブジェクトのフィールド順と配列要素の順序を分けて考えましょう。前者は通常、記述を整理するためのものですが、後者はルーティングやデフォルトoutboundの選択などに実際の影響を与えます。設定を結合する前に、トップレベルのキーが重複していないことも確認してください。重複キーは読み込み時に上書きされ、気付きにくい問題につながる場合があります。

まず起動できる基本設定を保存し、inbounds、outbounds、ルーティング、DNS、policyの順に項目を追加することをおすすめします。設定セクションを一つ追加するたびに再読み込みし、ログを確認してください。最後に変更した箇所に問題を絞り込めるため、複雑なファイルを何度も推測しながら修正せずに済みます。GUIクライアントが生成するファイルには、補助用の待ち受け口や内部タグが含まれる場合もあります。まず主要なデータの流れを整理してから、クライアントが自動管理する箇所を確認しましょう。

inbounds（待ち受け設定）

inboundsでは、コアがどこからトラフィックを受け取るかを定義します。ローカルクライアントではSOCKSやHTTPの待ち受け口がよく使われ、アプリは対応するプロキシプロトコルでそのポートに接続します。inboundはリモートサーバーではなく、最終的な接続先のoutboundを決めるものでもありません。トラブル時は、まずアプリがこの待ち受け口に実際に接続しているかを確認してください。リクエストがコアに届いて初めて、その後のルーティングやoutboundの設定が有効になります。ブラウザーでシステムプロキシを使う方法と、特定のアプリにSOCKSアドレスを個別に入力する方法は、別々の接続方法です。

待ち受けアドレス、ポート、プロトコル

listenでは待ち受けるローカルアドレスを指定します。個人用デバイスでローカルプロキシを使う場合は、待ち受け口をこの端末からの接続だけに限定できる127.0.0.1を優先してください。すべてのインターフェースにバインドするとアクセス範囲が広がるため、接続問題を解決する一般的な方法として使うべきではありません。portはアプリ側で指定したポートと一致し、ほかのプロセスで使用されていない必要があります。protocolはクライアントが待ち受け口と通信する方法を指定します。SOCKSポートにHTTPリクエストを送ると、プロトコルが自動変換されるのではなく、通常はハンドシェイクに失敗します。

SOCKSとHTTPの待ち受け口の違い

SOCKSの待ち受け口は、SOCKSプロキシに対応したアプリに適しています。settings.udpを有効にすると、待ち受け口でSOCKS UDP転送を扱えるようになりますが、アプリが対応するプロトコルを使用し、後続のoutboundやリモート接続経路もそのトラフィックを転送できる必要があります。HTTPの待ち受け口は通常、HTTPプロキシまたはCONNECTに対応したアプリ向けで、汎用のUDP入口ではありません。システムプロキシのスイッチが影響するのは、システム設定に従うアプリだけです。デバイス上のすべての接続がコアに入ると考えないでください。

{
  "inbounds": [
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

この設定例ではHTTPの待ち受け口を一つ追加します。前の章の基本設定と組み合わせる場合は、同じトップレベルキーをもう一度記述せず、既存のinbounds配列にこのオブジェクトを追加してください。ポート番号は例示用で、すべてのクライアントで固定されているわけではありません。v2rayNやAndroidクライアントでは、設定に応じて異なるポートが生成される場合があります。実際に使用中の値はクライアントで確認してください。待ち受けポートを変更したら、アプリ側のプロキシ設定も合わせて変更します。変更しないと、アプリは引き続き旧ポートに接続します。

宛先の識別と接続範囲

sniffingは、対応するトラフィックの特徴からドメイン名を取り出し、ドメインベースのルーティングに使える情報を補う機能です。すべてのトラフィックを復号する機能ではなく、どのような接続からでもドメイン名を特定できるわけではありません。対象範囲やルーティングだけに適用するオプションが各コアでサポートされているかも、それぞれ確認が必要です。最初に問題を切り分ける際は、まずクライアントのデフォルトの識別設定を維持し、通常のリクエストが届くことを確認します。その後、ドメイン情報が振り分けに影響しているかを順に調べ、待ち受け口の問題と識別処理の問題を混同しないようにしましょう。

LANからのアクセスを許可する場合は、バインドアドレス、認証、ファイアウォール、信頼できるネットワーク範囲をあわせて検討してください。listenを変更しただけで、ほかのデバイスから必ずアクセスできるとは限りません。また、待ち受け口をインターネットに公開してよいという意味でもありません。個人の端末内で使うなら、ループバックアドレスで待ち受けるほうが接続範囲を管理しやすくなります。ログにアドレスの使用中と表示された場合は、古いクライアントを終了するか、空いているポートを使ってください。接続の記録がまったくない場合は、アプリのプロキシアドレスと種類、ローカルプロキシを迂回するルールの有無を確認します。

TUNによるトラフィックの取り込みは、通常のSOCKSやHTTPの待ち受けとは異なる接続レイヤーです。クライアントは仮想ネットワークアダプターを使ってトラフィックをコアに渡せますが、アダプター名、権限、システムルートはクライアント側で管理されることが多く、一般的なinbound項目一つで説明できるものではありません。詳細はv2rayNのTUNモード設定メモをご覧ください。このセクションでは、アプリのプロキシ入口を調べているのか、仮想ネットワークアダプターによる取り込み経路を調べているのか、まず区別しましょう。

outbounds（送信先とデフォルト出口）

outboundsには、コアが使用する出口を設定します。宛先へ直接接続する出口、接続を拒否する出口、リモートプロキシ経由で転送する出口があります。ルーティングルールが選ぶのはoutboundタグであり、サブスクリプション画面の表示名ではありません。クライアントでノードを切り替えると、プロキシoutboundの接続先や認証パラメーターが再生成されることがよくあります。「ノードの選択」と「outbound JSONの編集」は、同じ接続経路に対する別の操作です。エクスポートした設定を読むときは、選択中のノードがどのoutboundに対応し、どのルールから参照されているかを確認してください。

プロトコル設定とトランスポート設定

protocolではoutboundのプロトコルを指定し、settingsにはそのプロトコルに必要な情報を設定します。VMessなどのリモートプロトコルでは、サーバーアドレス、ポート、ユーザーIDなどをサーバー側の設定と一致させる必要があります。streamSettingsには、使用するトランスポートやTLSの有無、サーバー名など、下位のトランスポートとセキュリティ層を設定します。プロトコルの認証とトランスポートの確立は別の段階です。あらゆる接続エラーをサーバーアドレスの誤りと決めつけないでください。

画面に表示されるサーバーアドレス、TLSのサーバー名、HTTP系トランスポートのHostは、役割が異なる場合があります。サーバーアドレスは接続先の特定に使い、TLSのサーバー名はハンドシェイクや証明書の検証に関わります。トランスポート層のHostは、該当プロトコルのリクエストパラメーターです。値が同じ場合もありますが、常に統一してよいわけではありません。変更する際は、サーバー管理者から提供された接続情報に従って一つずつ設定してください。証明書検証を安易に無効化すると、接続先の正当性や経路の問題が見えなくなるため、通常のトラブルシューティングとして適切ではありません。

直接接続、拒否、プロキシのoutbound

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

この例ではfreedomで宛先に直接接続し、blackholeでそのoutboundに振り分けられたトラフィックを拒否します。先頭の項目が直接接続なので、どのルールにもマッチしないリクエストはデフォルトで直接接続されます。拒否用outboundを先頭に移すと、ルールにマッチしないリクエストがすべて拒否される場合があります。ここにはプロキシoutboundがないため、リモートプロキシへの接続確認には使えません。実際のプロキシoutboundを追加する際は、デフォルトのトラフィックをプロキシ経由にするのか直接接続にするのかを決めたうえで、配列の順序や最後のフォールバックルールを設定してください。

コアの違いと接続機能

XrayとV2Flyには共通する設定方法もありますが、項目を自由に相互流用できるわけではありません。同じ名前の機能でも、値やデフォルト、サポート条件が異なる場合があります。特に新しいプロトコル、トランスポート、セキュリティ層、名前解決の方針は、使用中のコアが対応しているか確認してください。別のコアに設定を移す際は、プロトコルとトランスポートを確認し、その後に拡張項目を確認します。ファイル名がどちらもconfig.jsonだからといって、そのまま動くとは限りません。

UDPをoutboundで転送できるかどうかは、接続経路全体が対応しているかで決まります。inboundでUDPが許可され、outboundプロトコルが対応するトラフィックを転送でき、サーバー側でも転送が許可され、ネットワーク経路が到達可能である必要があります。どれか一つでも欠けると失敗することがあります。Webページが開けても、それは関連するTCPリクエストが使えることを示すだけで、音声通話やゲームなどのUDPアプリも同じ経路で通信できるとは限りません。一部のアプリだけに問題が起きた場合は、まず実際に使われているネットワークプロトコルを確認し、inbound、outbound、リモート側の転送設定のどこを調べるか判断しましょう。

初めて設定する場合は、v2rayNのノード編集またはサブスクリプションのインポート機能でリモートoutboundを生成し、このセクションと照らし合わせる方法がおすすめです。例の断片をもとに認証情報を補うことは避けてください。Androidでは、v2rayNGとv2flyNGで選べるコアが異なります。詳細はXrayとV2Flyのコア選定メモをご覧ください。トラブルの診断情報を共有する際は、必要な項目とエラーの種類だけを残し、サブスクリプションのURL、ユーザーID、その他の認証情報は伏せてください。接続情報一式がログから漏れないように注意しましょう。

routing（ルールとマッチ順）

routingでは、各リクエストをどのoutboundに渡すかを決めます。対象となるのはコアに届いたトラフィックであり、OSのルーティングを置き換えたり、プロキシ設定を無視するアプリを自動的に接続したりするものではありません。一般的にはrules配列を使い、各ルールで宛先のドメイン、IP、ポート、ネットワーク種別、inboundタグなどを調べます。ルールは先頭から順に評価され、マッチすると対応する処理が実行されます。条件が広すぎるルールが、後続の細かなルールを先に拾ってしまうことがあります。

ルール条件の組み合わせ方

フィールドルールでは、同じリスト内の複数候補は通常、そのうちいずれかに一致すればマッチします。たとえばdomain配列には複数のドメインを指定できます。一方、同じルールにある異なる条件フィールドは、すべて満たす必要があります。たとえばinboundTagとdomainを両方指定すると、指定したinboundから届き、かつ宛先ドメインがリストに一致するリクエストが対象になります。この条件を「いずれか一方」と誤解すると、ルールの範囲を想定より狭くしてしまいます。調査の際は条件を一つだけ残してマッチすることを確認し、その後、一つずつ制限を追加してください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "192.168.0.0/16"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

この設定例は、前の章の直接接続用outboundと拒否用outboundを組み合わせて使えます。blocked.exampleは完全一致の構文を示すための例示用ドメインで、それ以外の拒否対象でないリクエストは最終的に直接接続されます。最後のルールは明示的なフォールバックであり、プロキシへの振り分けを示すものではありません。デフォルトの接続先をプロキシにする場合は、実際のプロキシoutboundを用意してから、最後のルールに正確なタグを指定してください。定義されていないproxyをルールに記述しても、使用可能なoutboundが自動で作られるわけではありません。

ドメイン、IP、名前解決ポリシー

full:はドメイン名全体との一致に使い、domain:はそのドメインとサブドメインに一致させます。通常の文字列と正規表現では意味が異なるため、見た目だけで対象範囲を判断してはいけません。IP条件には単一のアドレスまたはCIDR形式のネットワークを指定できます。地理情報の分類データを使う場合は、実行環境に必要なデータファイルがあり、カテゴリ名が正しく、更新元が信頼できることも確認してください。問題を切り分けやすくするため、最初は特定のドメイン名やIPアドレス一つでテストし、その後に大きな分類リストを追加しましょう。

domainStrategyでは、ルーティング時にドメイン名の名前解決をどのように使うかを指定します。AsIsはリクエストに含まれる宛先情報をそのまま使います。IPIfNonMatchはドメインルールで振り分け先が決まらない場合に名前解決を試し、IPルールの評価を続けることがあります。IPOnDemandは、IP情報が必要なマッチ判定で名前解決を行います。具体的な動作範囲は使用するコアの仕様を確認してください。選択時には、名前解決の負荷、DNSサーバーへの到達性、フォールバックルールの位置を考慮します。積極的に名前解決するほど正確になるとは限りません。

元のリクエストにIPアドレスしか含まれていない場合、ドメインルールにマッチしないことがあります。アプリがOS側ですでに名前解決している場合や、独自の暗号化DNSでアドレスを取得している場合もあります。inboundの宛先識別で補えるドメイン情報も、対応する一部のトラフィックに限られます。反対に、ドメイン名を含むリクエストでも、IPルールで使えるアドレスをすぐに取得できるとは限りません。ルールを調べる際は、ブラウザーのアドレスバーから推測せず、ログでコアが実際にどの宛先を認識しているか確認してください。

ルールの管理と動作確認

拒否ルール、特定サービス向けルール、LAN向けルール、フォールバックルールを、役割が分かる順に整理することをおすすめします。ルールを追加するたびに、想定する宛先とoutboundを記録し、それより前のルールに先にマッチしないか確認してください。ルールの並べ替えは見た目を整えるだけの作業ではありません。位置を変えると実際の動作も変わることがあります。クライアントにルーティングのプリセットがある場合は、プリセットがカスタムリストを上書きするか、モード切り替えで設定セクション全体が再生成されるかを確認しましょう。

主要な3つの設定セクションの関係については、inbounds・outbounds・routingの項目別解説もご覧ください。よく使うアプリのトラフィックをどこまで取り込むか変更したい場合は、コアのルーティングを編集する前に、クライアントのシステムプロキシまたはTUNの状態を確認してください。アプリがまだ接続されていない場合、ドメインルールを追加しても実際の接続経路は変わりません。

dns（名前解決サーバーとドメイン別設定）

dnsではコア内蔵のリゾルバーを設定しますが、デバイス上のすべてのDNSリクエストを自動的に取り込むわけではありません。システムの名前解決、アプリ独自の名前解決、ルーティングのためにコアが行う名前解決、リモートoutbound側の名前解決が同時に存在することがあります。設定を読む前に、どのレイヤーでアドレスが必要なのかを確認してください。アプリからすでにIPが渡されている場合、内蔵DNSの変更がその接続に影響しないことがあります。ルーティングでドメイン名をIPアドレスに変換する必要がある場合は、内蔵リゾルバーがルールの選択に影響する可能性があります。

serversリストとサーバーオブジェクト

serversには、簡単なサーバー項目のほか、ドメイン範囲などの条件を持つサーバーオブジェクトも指定できます。localhostはOSの名前解決を使う指定で、最小限の診断設定に適しています。ただし、結果はシステムDNS、ネットワーク、本体の設定にも左右されます。パブリックDNSサーバーのアドレスを指定しただけでは、クエリが必ずプロキシを通ることや、期待どおりの結果が得られることは保証されません。サーバーへの接続可否やクエリの送信経路は、使用するコアと関連するルーティング設定に基づいて確認してください。

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "domains": ["domain:example.com"],
        "expectIPs": ["93.184.216.0/24"]
      },
      "localhost"
    ]
  }
}

ここでは、例示用のドメインを使って、問い合わせ先の限定と応答結果のフィルタリングを説明します。expectIPsのアドレス範囲はフィルター構文の例であり、そのドメインから現在この範囲のアドレスが返ることを示すものではありません。ドメインのアドレスは変わるため、そのまま流用するとフィルターに失敗する可能性があります。実際に使う場合は、自分が管理する名前解決の範囲に合わせて設定してください。想定アドレスが分からない場合は、この条件を削除しておきます。この例は、最初のサーバーへの問い合わせがプロキシ経由になるとも示していません。診断ではクエリの経路を個別に確認してください。

domains、expectIPs、フォールバック

domainsは、特定のサーバーを優先して使うドメインの範囲を示すもので、ルーティングの最終的な出口を決めるものではありません。expectIPsは名前解決の結果に期待するアドレス範囲を指定し、想定と異なるアドレスを検出するためのものです。DNSの応答を自動で正しい値に修正する機能ではありません。範囲が狭すぎたり古くなったりすると、正当な応答が除外され、本来アクセスできるドメインの名前解決に失敗する場合があります。設定する前に、対象ドメインのホスティング方法とアドレスの安定性を確認してください。

どのサーバーを優先し、どのサーバーを使わないか、クエリが失敗した際にどうフォールバックするかは、使用するコアや関連スイッチに左右されます。サーバーの配列内での位置だけを見て、すべてのクエリが厳密に順番どおり実行されると判断しないでください。特定のサーバーを通常のフォールバックで使わないようにする場合は、まず対象コアの該当フィールドの意味を確認し、小さな範囲でテストします。複雑な振り分けを設定する前に、サーバーごとに対象ドメインを解決できるか確認しましょう。一度に複数の制限を追加するより、問題を特定しやすくなります。

名前解決ループ、キャッシュ、アドレスファミリー

暗号化DNSの接続先を指定する場合、そのホスト名自体の名前解決が必要になることがあります。その名前解決が、まだ確立していない同じ名前解決経路に依存すると、起動時に依存関係のループが発生します。解決するには、サーバー名を次々と変えるのではなく、初期の名前解決とクエリの送信先を整理してください。ローカルクエリ、リモートクエリ、DNS用のルーティングタグへの対応はコアごとに異なります。コアを移行する際は特に再確認し、トランスポート名だけから動作全体を判断しないでください。

IPv4とIPv6の結果も区別してください。IPv6アドレスを取得できても、使用中のoutboundに利用可能なIPv6経路があるとは限りません。IPv4だけを問い合わせる設定も、すべてのネットワークに適しているわけではありません。テストでは名前解決結果のアドレスファミリーを記録し、実際に接続に失敗したアドレスと照らし合わせます。DNSを変更した後は設定を再読み込みし、新しい接続を試してください。OS、アプリ、コアそれぞれにキャッシュがあり、古い結果がしばらく確認に影響することがあります。一度ページを再読み込みしただけで、設定が反映されていないと判断しないでください。

DNSではサーバー数を増やすことより、名前解決の場所、クエリの経路、接続先のoutboundを一致させることが重要です。ドメイン範囲ごとに名前解決先を分ける場合は、DNSの振り分け設定メモを参考に項目を確認してください。根拠のない長いリストを管理するより、検証済みのルールを少数に絞り、それぞれの対象範囲を明記するほうが安定します。

policy（接続段階とユーザーレベル）

policyはルーティングルールでも、クライアント全体のトラフィック取り込みモードでもありません。主に接続の各段階、アイドル状態、一部の統計処理に関するポリシーを設定します。よくある誤解は、時間制限をネットワーク高速化の設定と考えることです。待ち時間を短くしても、失敗が早く分かるだけで、実際の回線遅延は小さくなりません。制限が厳しすぎると、回復する可能性がある接続まで切断されることがあります。具体的な問題がない場合は、コアのデフォルト値を優先してください。

levelsとlevelの対応関係

levelsでは、ユーザーレベルをキーにして、各レベルに一連のポリシーを設定します。JSONオブジェクトのキーは文字列なので、例では"0"と記述します。一方、ユーザーレベルに対応するプロトコルのユーザー設定では、levelは通常数値です。この二つは対応付けられるものであり、同じフィールドではありません。レベルを定義しただけで、すべての接続に自動適用されるわけではありません。関連するプロトコルでユーザーコンテキストが作られるか、そのユーザーにどのレベルが割り当てられているかによって有効性が決まります。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    }
  }
}

この設定例はポリシーオブジェクトの構造を示すもので、秒単位の数値がすべてのネットワークに推奨されるわけではありません。ユーザー、outbound、待ち受け口を作成するものではなく、すべてのプロトコルに制限が適用される保証もありません。クライアントにユーザーレベルの設定項目がない場合は、まず生成された設定内で実際にどのように対応付けられているか確認してください。levelsはノードの優先順位リストではありません。数値が大きくても、ノードが速くなったりルーティングの優先順位が上がったりするわけではありません。

ハンドシェイク、アイドル、片方向接続

handshakeは、関連する接続の確立時に許容する待ち時間を設定します。認証やハンドシェイクに時間がかかるネットワークでは、短く設定しすぎると再試行が続くことがあります。connIdleは、データのやり取りがない接続のアイドル時間を設定します。実際の動作はプロトコル、アプリのキープアライブ、中継するネットワーク機器の影響も受けます。コア側で長いアイドル時間を許可しても、ルーターやリモートサービスが先に接続を切ることがあります。値を延ばすだけで長時間接続が維持されるとは限りません。

uplinkOnlyとdownlinkOnlyは、片方向のデータ送信が終わった後に、残りの接続をどれだけ待つかを設定します。アップロードやダウンロードの速度上限ではありません。上り・下りは接続内のデータ処理方向を指し、速度テスト画面で使われる意味とは異なります。アプリによっては先に送信を終え、サーバーからの応答を待つことがあります。残りの待ち時間を短くしすぎると、応答が届く前に接続が切れる場合があります。このような問題を調べる際は、画面にタイムアウトが表示されたかだけでなく、接続がいつ半閉鎖されたかも確認してください。

統計スイッチとクライアント画面の表示

一部のポリシーでは、ユーザーまたはシステム単位のトラフィック統計を制御できます。ただし、ポリシーのフィールドを有効にしただけでは、統計を取得して表示するための仕組み全体がそろうとは限りません。コアに統計モジュールや管理インターフェースが必要だったり、クライアントがその情報を読み取る必要があったりします。ユーザーごとの統計には、プロトコル上のユーザーIDが必要な場合もあります。画面にトラフィックが表示されても、すべてがpolicy由来とは限りません。反対に、画面に表示されないからといって、接続がコアを経由していないとは断定できません。統計の問題は接続の問題と分け、まずリクエストが正常に処理されることを確認してください。

リモート管理が不要なら、統計を表示するためだけに管理用ポートを不用意に公開しないでください。クライアントが内部インターフェースを管理している場合は、デフォルトのアクセス範囲を維持し、カスタム設定がその入口を上書きしていないことを確認します。統計フィールド、メモリ関連のオプション、デフォルトポリシーにはコアごとの差があります。拡張フィールドを多数含むポリシーをコピーすると、起動できなくなるリスクが増えるだけの場合があります。用途を一つずつ確認し、説明できず必要性もない項目は削除してください。

変更後の確認には、短いリクエスト、継続的なデータ転送、アイドル状態からの再開の3種類を含めてください。通常のWebページを一度表示するだけでは、長時間接続に適したポリシーかどうか分かりません。変更前後の値、実際に待った時間、エラーの種類を記録し、安定した改善が見られなければデフォルトに戻します。ハンドシェイク、アイドル時間、クライアントの複数のスイッチを同時に変えるより、小さな範囲で調整するほうが検証しやすくなります。

クライアントが生成する設定と再読み込み

GUIクライアントに保存される設定と、コアが最終的に読み込むJSONは同じとは限りません。サブスクリプショングループ、ノード名、画面テーマ、システムプロキシ、自動起動などは通常クライアント側の設定です。一方、inbounds、outbounds、ルーティング、DNSは、それらの設定に基づいてクライアントが生成することがあります。実行ディレクトリ内のファイルを直接編集しても、次回の起動やノード切り替え時に上書きされる場合があります。変更前に設定の生成元を確認すれば、画面から変更すべきか、クライアントが提供するカスタム設定機能を使うべきか判断できます。

サブスクリプション、ノード、完全な設定の違い

サブスクリプションには通常、複数の接続情報が含まれます。クライアントがそれを解析して保存し、outboundを生成します。ノードの共有情報は、リモート接続一つ分の記述が中心で、ローカルの待ち受け口やルーティング全体を含むとは限りません。コアの完全な設定には、実行に必要な各要素がそろっている必要があります。ノード情報をconfig.jsonとして保存しても、自動的にJSON形式の設定になるわけではありません。dnsだけの断片を「完全な設定」として読み込むと、必要なinboundやoutboundが不足する場合があります。内容の種類に合ったインポート機能を使ってください。

v2rayNは、デスクトップ環境でのノード管理や設定の確認に適しています。Androidでは必要なコアに応じてv2rayNGを優先し、V2Flyの設定が必要な場合はv2flyNGを検討してください。3つのクライアントはメニュー名や対応する設定項目が同じとは限りません。特定のクライアントの操作画面を、すべてのコアに共通する仕様として扱わないでください。ダウンロード先とプラットフォームの選択についてはクライアント一覧を、インポートから接続確認までの手順については入門ガイドをご覧ください。

変更前の状態を保存する

使用中のクライアント、OS、選択したコア、トラフィックの取り込み方法、再現可能な問題を記録してください。現在の設定を保存するか、必要な設定をエクスポートし、サブスクリプションのURLと認証情報は機密情報として別に管理します。診断用のバックアップを公開場所に安易にアップロードしないでください。DNSルールを一つだけ試すなら、ノードとルーティングは変更しません。コアを切り替える場合は、サブスクリプションの更新やトランスポートの変更を同時に行わないようにします。変更する要素を一つに絞れば、失敗の原因が明確になり、元に戻しやすくなります。

カスタム設定を使用する場合、クライアントが内部の待ち受け口、統計設定、ルーティングを引き続き追加するか確認してください。完全な設定として読み込む方法もあれば、特定の項目だけを上書きする方法もあり、結合の仕方が異なります。確認すべきなのは、編集画面の一部分ではなく、最終的にコアへ渡される実行用設定です。エクスポート機能がノード情報しか出力しない場合、それを実行設定全体のスナップショットとして扱うことはできません。現在のモードと全体設定もあわせて確認してください。

保存、読み込み、新しい接続の確認

1. JSONの構文とタグの参照先を確認し、予定した設定セクションだけを変更したことを確かめます。
2. クライアントで設定を保存し、用意されている再読み込み、サービスの再起動、または再接続の操作を実行します。
3. 起動ログで新しいコアのプロセスが読み込まれたことを確認し、待ち受けポートの使用中エラーがないか調べます。
4. テスト用の新しい接続を確立し、リクエストが想定したinboundに届き、意図したoutboundが選ばれるか確認します。
5. 結果が想定と異なる場合は、直前の設定に戻して基本設定が引き続き使えることを確認し、差分を調べます。

設定を保存しただけでは読み込み済みとは限らず、読み込んでも既存の接続がすぐ新しいoutboundへ切り替わるとは限りません。ブラウザーなどのアプリは既存の接続を再利用する場合があり、DNSがキャッシュされていることもあります。ルーティングの変更をテストするときは新しいリクエストの接続を確立し、必要に応じてアプリを終了して再試行してください。開いたままのページで操作を続けるだけでは不十分です。クライアントのログに今回のテスト時刻に対応するイベントがあることも確認してください。そうでなければ、表示されているのは以前の接続の記録かもしれません。

Windows、macOS、Linuxでは、システムプロキシに従う仕組みやバックグラウンドでの動作が異なります。ボタン名が同じだからといって、動作も同じとは限りません。Linuxデスクトップの自動起動は、デスクトップ環境やインストール方法にも左右されます。詳しくはLinuxのインストールと自動起動に関するメモをご覧ください。AndroidのシステムVPNの許可、アプリ別の振り分け、バックグラウンド制限も接続環境に関わるため、JSONのルーティングとは分けて確認します。

最後に、元に戻す手順を確認してください。使用可能なノード、元のモード、変更前の設定を残し、診断のための変更を普段使う設定にそのまま置き換えないようにします。クライアントの更新後に項目が受け付けられなくなった場合は、まず生成設定のデフォルトテンプレートに戻し、コアの対応状況を確認してください。古い項目を次々と追加して、内容を説明できない設定ファイルを維持するのは避けましょう。カスタム項目の用途を明確に説明できる状態にしておけば、その後の管理も容易になります。

設定の検証とトラブルシューティングの順序

設定のトラブルシューティングは、データの流れに沿って進めます。まずファイルを読み込めること、次にinboundがリクエストを受け取ること、続いてルーティングが正しいoutboundを選ぶことを確認し、最後に名前解決、ハンドシェイク、接続先からの応答を調べます。一度に検証する項目は一つに絞ってください。ノード、DNS、ルーティング、タイムアウトをまとめて変更すると、接続が偶然復旧してもどの変更が有効だったのか分かりません。一定のテスト先、同じ接続方法、対応するログを用意すれば、変更前後の差を正確に比較できます。

起動に失敗する場合は最初のエラーを確認

ファイルを読み込めないときは、後続の連鎖的な終了メッセージではなく、最初に表示された明確なエラーを確認します。括弧やカンマの誤りはJSON構文の問題です。未対応のプロトコル、フィールド型の不一致、必須パラメーターの不足は設定内容の問題です。アドレスの使用中、権限不足、ファイルパスを読み取れないといった問題は実行環境に関係します。それぞれ対処する場所が異なります。エディターで構文エラーがないと確認できても、実際に使用するコアで検証してください。別のコアで成功しても、代わりの確認にはなりません。

エラーが特定の設定セクションを示している場合は、まずそのセクションを直近の変更前の状態に戻してください。設定ファイルを結合した場合は、トップレベルキーの重複、配列の誤った置き換え、数値が文字列に変わっていないか確認します。ポートが使用中なら、複数のクライアントが同時に起動していないか調べ、古いプロセスを終了してから再試行してください。権限に関する問題では、必要なリソースと操作を具体的に確認します。仮想ネットワークアダプターの作成に必要な権限と、ローカルの高位ポートで待ち受ける権限は異なります。一般的な設定エラーだけを理由に、すべての操作を常に高い権限で実行しないでください。

起動するが接続できない場合は、範囲を絞って確認

inboundにリクエストがまったく届かない場合は、アプリのプロキシアドレス、ポート、種類、システムプロキシの状態を確認します。リクエストは届くもののoutboundが違う場合は、ルールの順序、宛先に含まれる情報がドメインかIPか、タグの参照先を確認してください。正しいoutboundが選ばれているのに接続できない場合は、名前解決、リモートサーバーへの到達性、認証、トランスポート設定を調べます。特定の接続先だけが失敗するなら、接続先サービス自体の状態も考慮してください。それだけで設定全体が壊れているとは限りません。LAN内の接続に問題がある場合は、フォールバックルールで不適切なoutboundに送られていないか確認します。

ログの詳細度と最小再現手順

診断中は一時的にログの詳細度を上げ、inbound、ルーティング、接続のエラーを確認できます。ログには宛先ドメイン、アドレス、利用状況が含まれることがあるため、収集範囲を必要最小限にし、問題の解決後は通常のログレベルに戻してください。ログを共有する前に接続情報を伏せ、エラーの説明に必要なデータだけを残します。サブスクリプションの内容や認証情報一式を質問に貼り付けないでください。多くの設定問題は、項目の構造、エラーの種類、加工して秘匿した宛先情報で説明できます。

{
  "log": {
    "loglevel": "info"
  }
}

この設定例ではログレベルだけを変更します。ログの保存先はクライアントが管理する場合があるため、ファイルパスを指定していない場合はクライアントのログ画面を確認してください。詳細度を上げたら、対象のリクエストを一度送信して前後のイベントを記録し、その後は元のレベルに戻します。一つの問題を調べるために、すべてのアプリの動作を長時間記録しないでください。情報レベルのログで処理段階を特定できない場合は、コアが対応していることを確認してから、さらに詳細なログレベルを短時間だけ使用します。

最小構成での再現テストは、このページの最初にある直接接続の基本設定から始めます。ローカルの待ち受け口と通常のネットワーク接続を確認してから、実際のプロキシoutboundを戻してください。基本設定で直接接続できても、プロキシ経路が正常だとは限りません。ここで除外できるのは、ローカルの接続問題の一部だけです。その後、ルーティング、DNS、policyを順番に戻し、各段階で再読み込みして新しい接続を確立します。直接接続テストに適さないサービスの場合は、無理にアクセス経路を変えず、自分で管理しているテスト先で同じ設定段階を確認してください。

よくある質問と関連ガイド

このページでは設定項目の参照とレイヤー別のトラブルシューティングを扱います。初めて操作する場合は入門ガイドを、プロトコルやエコシステムの用語については用語解説をご覧ください。トラブルシューティング後は、変更した設定セクション、確認できた結果、再読み込みの要否、元に戻す方法を簡潔に記録しておきましょう。説明でき、再現でき、元に戻せる設定は、パラメーターを増やし続けるよりも保守しやすくなります。