v2rayN
入手と設定ガイド

サブスクリプションを使うと、複数のサーバー設定を1つの更新先にまとめられます。まずグループを作成し、使用権限のあるURLを貼り付けて更新した後、設定が一覧に反映されたことを確認してください。通常の更新に失敗した場合は、既存の接続が使えることを確認したうえで、プロキシ経由の更新を試せます。サブスクリプションURLにはアクセス情報が含まれることがあるため、スクリーンショットや公開ログに載せないでください。設定を1件ずつ手入力する方法に比べ、グループで管理すると取得元や更新範囲を把握しやすくなります。ただし、独自のメモ、並び順、ルーティングルールは別途バックアップしてください。リモートからの更新内容がローカル設定の恒久的な保存先になるわけではありません。右側の例はJSONでURLを保存する形式を示したもので、クライアントのサブスクリプションファイル形式ではありません。

{
  "url": "https://example.com/sub"
}

VMess、VLESS、Trojanはそれぞれ異なる送信プロトコルで、自由に置き換えられるラベルではありません。取り込み後は、ポート、トランスポート方式、TLSなどのセキュリティ設定も確認してください。同じプロトコルでも、すべてのパラメーターに互換性があるとは限りません。GUIクライアントでは複数の設定を保存して切り替えられますが、実際に動作するかどうかは選択したコアによって決まります。まずサーバーから提供されたパラメーターをそのまま使い、接続を確認してからトランスポート設定を調整しましょう。右側の例はdirectとblockという基本的な送信先を示しており、ルーティングからtagを参照する仕組みを理解するためのものです。接続先のサーバー情報は含まれていないため、利用可能なプロキシ設定の代わりにはなりません。

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

ルーティングは、接続をどの送信先に渡すかを決めます。ルールは上から順に照合されるため、例外は通常、広範囲に適用するルールより前に置きます。geositeはドメインの集合、geoipはIPアドレスの集合を扱い、それぞれ対応するデータベースを利用します。最初は、LAN内のアドレスを直接接続にするなど、明確なルールを少数だけ設定しましょう。その後、必要なドメインを1つずつ追加します。すべての通信を同じ送信先に流す場合と比べて、ルーティングを使うとローカルサービスへの影響を抑えられますが、ルールの順序と送信先のタグを管理する必要があります。例にあるdirectは、送信先として実際に設定されていなければなりません。変更後は具体的な接続先で照合結果を確かめ、ルールが保存されたことだけで有効と判断しないでください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

DNS設定は、リゾルバーのアドレスを入力するだけではありません。どのアプリが問い合わせを行うか、どの経路で問い合わせるか、結果をルーティングにどう使うかも関係します。コア内蔵のDNSが、システム上のすべてのアプリの名前解決を自動的に処理するわけではありません。ドメインにアクセスできない場合は、まず名前解決の失敗と接続の失敗を切り分け、問い合わせのポリシーと実際の送信先を確認してください。リゾルバーを何度も変更するより、アプリ、システム、コアそれぞれの役割を明確にすることが大切です。右側の例はDNSサーバー一覧とIPv4の問い合わせポリシーを示したもので、すべてのネットワークに適した推奨値ではありません。変更前に元の設定を記録し、一度に1項目だけ変更すれば、何が影響したのか判断しやすくなります。

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "localhost"
    ],
    "queryStrategy": "UseIPv4"
  }
}

システムプロキシは、システム設定に従うアプリをローカルプロキシの入口に接続します。TUNは仮想ネットワークインターフェースを使って通信を処理します。必要な権限と影響範囲はそれぞれ異なります。初回の設定では、まずシステムプロキシで接続を確認し、必要に応じてTUNを検討してください。右側の例はローカルSOCKSの受信設定で、TUNの設定ではありません。ループバックアドレスで待ち受けると、接続できるのは同じ端末上のアプリだけです。LAN全体で待ち受ける場合と比べ、アクセス範囲を管理しやすい設定です。他の端末から接続する必要がある場合は、待ち受けアドレスを全インターフェースに変更するだけでなく、ファイアウォール、認証、ネットワーク境界もあわせて確認してください。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ]
}

クライアントの画面とプロキシコアはそれぞれ役割が異なります。画面にあるオプションが、現在のコアで必ず認識されるとは限りません。切り替える前に、設定で使っているプロトコル、トランスポート、セキュリティ機能を確認し、コアの対応範囲を調べてください。名称だけで判断するより、起動ログを確認するほうが、未対応の項目やパラメーターを特定しやすくなります。利用できる設定をバックアップし、切り替え後は最小限の接続テストを行ってから、独自のルーティングやDNS設定を戻しましょう。右側の例は一般的なログレベルを示したもので、コアを選ぶためのスイッチではありません。通常、コアはクライアントの設定画面で選びます。JSONに独自のフィールドを追加して切り替えることはできません。

{
  "log": {
    "loglevel": "warning"
  }
}