Xrayの設定ファイル構成を解説｜inbounds・outbounds・routingの読み方

設定オブジェクトと通信経路

Xrayは接続を処理するコアで、v2rayNはノードを管理し、設定を生成してコアを起動するデスクトップクライアントです。ノード共有リンクに記載されるのは通常、1つのリモート接続情報です。一方、ネイティブJSONではローカルの待ち受け、複数の出口、ルーティング、DNSをまとめて設定できます。共有リンクをconfig.jsonとして保存しても、そのまま実行可能なコア設定にはなりません。

この流れが設定を読む際の基本です。logは状態を記録し、dnsは名前解決が必要な場合に処理に関わります。どちらも、すべてのリクエストが順に通過する独立した中継地点ではありません。JSONでのトップレベル項目の記述順も、通信の順序を決めるものではありません。

• inbounds：通信の入口と、使用するローカルプロトコルを設定します。
• outbounds：コアからの接続方法を設定します。直結、プロキシ、遮断から選べます。
• routing：宛先や送信元に応じて、使用するoutboundタグを選びます。
• dns：内蔵DNSを設定します。実際に使われるかどうかは、関連する名前解決設定にも左右されます。

設定JSONの全体例：ローカル入口と直結の基本構成

以下は構成を理解するための単体設定例です。SOCKS入口は127.0.0.1:10808、HTTP入口は127.0.0.1:10809で待ち受けます。リモートプロキシノードは含まれていません。通常のリクエストは直結し、予約済みのテスト用ドメインblocked.test宛てのリクエストは遮断します。リモートプロキシの動作確認には使えません。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:blocked.test"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ],
        "outboundTag": "direct"
      }
    ]
  },
  "dns": {
    "servers": [
      "localhost"
    ]
  }
}

この例は厳密なJSONです。キー名と文字列はダブルクォートで囲み、コメントは付けず、配列の最後の要素の後にカンマを置きません。後述する各項目の説明はこの設定を解説するもので、項目ごとに組み合わせて別の設定を作る必要はありません。

log：エラーの発生箇所を特定する

loglevelでエラーログの詳細度を設定します。よく使われる値はdebug、info、warning、error、noneです。トラブルシューティング中は、例のwarningを一時的にinfoへ変更できます。確認後は元に戻し、接続の詳細を過剰に記録しないようにしましょう。

この例ではログファイルのパスを指定していません。コマンドラインから実行する場合は、まずコンソールを確認してください。accessやerrorを追加する場合は、実行中のプロセスが書き込めるパスを選び、相対パスと起動時の作業ディレクトリの関係にも注意します。ログにアクセス先が記録されることがあるため、トラブルシューティングの内容を共有する前に機密情報を削除してください。

• 起動前にJSON解析エラーが出る場合は、括弧、カンマ、項目の型を確認します。
• 起動時にaddress already in useと表示された場合は、まずローカルポートを確認します。リモート側のプロトコルを先に変更しないでください。
• 入口でリクエストを受け付けた後に接続がタイムアウトする場合は、実際に使われたoutbound、名前解決の結果、接続先への到達性を確認します。

inbounds：待ち受けアドレス、ポート、入口タグ

各inboundオブジェクトは、通信を受け付ける入口です。listenはバインドするアドレス、portは待ち受けポート、protocolはアプリが接続に使うプロトコルを指定します。tagは設定内で使う識別子であり、パスワードでもブラウザーに入力するホスト名でもありません。

127.0.0.1はローカルマシンからの接続のみを受け付けます。0.0.0.0に変更すると、IPv4の待ち受け範囲が広がります。他の端末からアクセスできるかどうかは、ファイアウォールやネットワーク環境にも左右されます。この例のSOCKSはnoauthを使用するため、LANで共有しようとして安易に待ち受け範囲を広げないでください。

• ブラウザーがシステムのプロキシ設定を使う場合は、実際のHTTP入口を指定してください。2つのポートを取り違えないようにします。
• ローカルポートはリモートサーバーのポートではありません。10808を変更しても、ノード側のサーバー設定は変わりません。
• udp: trueはSOCKS inboundのUDP機能を有効にするだけで、HTTP入口が通常のUDP通信を自動的に処理するわけではありません。

outbounds：出口プロトコルとデフォルトの出口

outboundsは、ルーティングで選択できる出口の配列です。この例ではfreedomが宛先へ直接接続し、blackholeが接続を遮断します。directとblockは任意に付けたタグです。動作を決めるのはタグの英語の意味ではなく、protocolです。

リモートプロキシの出口を追加する場合は、プロトコル、サーバーアドレス、ポート、認証情報、トランスポート設定を整合させる必要があります。freedomをvlessに変更するだけでは、ノードの設定は完了しません。TLSやREALITYの項目は該当するトランスポートのセキュリティ設定に含めます。inbound SOCKSのsettingsに適当に追加しないでください。

routing：ルールの順序、タグ参照、名前解決の方針

routing.rulesは配列の順に照合され、最初に一致したルールで出口が決まります。この例では、1つ目のルールで完全一致するドメインblocked.testをblockへ送り、2つ目のルールで指定したIPv4ネットワークをdirectへ送ります。これらのネットワークは例示用であり、特殊用途アドレス全体を網羅するものではなく、IPv6も含みません。

1. リクエストを受け取ると、コアは入口タグ、宛先のドメイン名やIPアドレス、ポートなど、利用可能な情報を取得します。
2. 先頭のルールから順に確認します。同じルール内で異なる種類の条件が指定されている場合、通常はすべての条件を満たす必要があります。
3. 同じ種類のリスト内にある候補は、通常はいずれかに一致すれば条件を満たします。たとえば、ip配列内のいずれかのネットワークに一致する場合です。
4. 一致するルールが見つかったら、そのoutboundTagを使います。一致しない場合はデフォルトの出口を使います。

full:はドメイン名の完全一致、domain:はドメイン名とそのサブドメインへの一致に使います。特定の入口に適用対象を限定するには、ルールにinboundTag配列を追加できます。参照するタグは、対応するオブジェクトのtagと一致させてください。入口タグと出口タグは用途が異なるため、socks-inをoutboundとして参照することはできません。

この例ではAsIsを指定しているため、ドメイン名で送られたリクエストは、2つ目のIPルールとの照合だけを目的に名前解決されません。ただし、デフォルトの出口は直結です。そのため、リクエストが直結したからといって、プライベートネットワークのルールに一致したとは限りません。ルールを調べる際は、最終的にページを開けるかどうかだけでなく、実際に一致したルールと出口を確認してください。

dns：ルーティング時の名前解決と接続時の名前解決

dnsを設定しても、すべてのアプリのDNSを引き受けるわけではありません。アプリが先に名前解決してIPアドレスをプロキシへ渡す場合もあれば、ドメイン名をSOCKSやHTTP入口へ渡す場合もあります。ルーティングで利用できる情報は、まず入口が実際に何を受け取ったかによって決まります。

この例ではdns.serversに特殊値localhostを指定しています。これはローカルシステムのリゾルバーを使って名前解決するという意味で、ローカルマシン上で動作するDNSサーバーを指定するものではありません。また、UDP 53番ポートで待ち受ける設定も作成されません。アプリにDNSサービスを提供するには、DNSリクエストを受け取る入口と処理経路を別途設計する必要があります。

• routing.domainStrategy：ルーティングの照合時に、ドメイン名をIPアドレスへ変換するかを指定します。
• freedom.settings.domainStrategy：直結outboundで宛先ドメインをどう処理するかを指定します。
• dns.servers：内蔵DNSが使う名前解決先を指定します。実際に呼び出されるタイミングは、関連機能によって決まります。

この例では、freedom outboundにUseIPを設定し、直結時に内蔵DNSの名前解決を使います。これはルーティングのAsIsと矛盾しません。前者はoutboundが接続を準備する段階で適用され、後者はルール照合の段階を制御します。outboundで後からIPアドレスを取得しても、すでに終了したルーティング判定が自動でやり直されることはありません。

検証とトラブルシューティング：設定確認から実際の接続まで

まずコア付属のチェックコマンドで設定を検証し、次に待ち受けを起動して、最後にアプリを接続します。以下のコマンドは、実行ファイルxrayを見つけられるターミナルで実行してください。コマンド検索パスにない場合は、実際のファイルパスを指定します。先にバージョンとヘルプを確認すると、現在のバイナリで使えるオプションを把握できます。

xray version
xray run -help
xray run -test -config ./config.json
xray run -config ./config.json

設定チェックに合格しても、コアが設定を受け付けたことを示すだけです。リモートサービスへの接続や、アプリがプロキシを使っていることまでは保証されません。再現可能なローカルテストを行う場合は、別のターミナルでテスト用サーバーを起動し、2つの入口からそれぞれアクセスします。

python -m http.server 8000 --bind 127.0.0.1

curl --noproxy "" --proxy socks5h://127.0.0.1:10808 http://127.0.0.1:8000/
curl --noproxy "" --proxy http://127.0.0.1:10809 http://127.0.0.1:8000/

テストにはPythonとcurlがローカルにインストールされている必要があります。応答はローカルのテスト用ディレクトリから返されます。検証するのは「アプリから入口へ接続し、ルールで振り分け、直結outboundで接続する」という経路です。--noproxy ""は、既存のプロキシ除外設定によって今回の入口テストがスキップされるのを防ぎます。テスト後は一時サーバーを停止してください。ターミナルに表示されるディレクトリ一覧を、プロキシノードの速度測定結果と見なさないでください。

基本構成の検証が済んだら、リモートプロキシのoutboundを追加し、明確なルールを設定します。一度に変更するのは1か所だけにし、動作する直前の設定も残しておきましょう。問題が起きたとき、入口、ルール、名前解決、リモート接続のどこに原因があるか絞り込みやすくなり、関係のない設定を何度も切り替えずに済みます。