サブスクリプションのインポートとローカルリスナー
サブスクリプションはサーバー設定をまとめて取得するためのもので、接続の確立を意味するものではありません。v2rayNのサブスクリプショングループにURL全体を保存して更新します。Androidでも先にグループを追加し、設定を更新してください。リストに項目が表示されたら、使用するサーバーを選んで接続をテストします。以下はローカルSOCKSインバウンドの例で、サブスクリプションの内容とは別の階層です。ループバックアドレスで待ち受ける場合、接続できるのは同じ端末からだけです。更新に失敗したら、まずサブスクリプション取得時のログを確認してください。リモートアドレスの問題を直すためにインバウンドポートを変更しないでください。
{
"inbounds": [
{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
}
]
}
インバウンド設定のリファレンスを見る →
ルーティングルールは上から順に適用
ルールはリクエストの出力先を決めるもので、サーバー自体の問題を解決するものではありません。プロキシ用と直結用の出力にわかりやすいタグを付け、具体的なルールから書き、最後にデフォルトの出力先を設定しましょう。以下ではプライベートアドレスをdirectという出力先に割り当てています。このタグは完全な設定内に存在し、参照するルールデータも利用可能でなければなりません。意図しない振り分けを調べるときは、先に一致したルールと、ドメインがIPアドレスに変換済みかを確認してください。ルール名だけで結果を判断したり、複数のルールを同時に変更したりしないようにしましょう。
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}
ルーティングルールのリファレンスを見る →
システムDNSとコア内蔵DNSを区別する
Webページが開けない原因は、サーバーの停止だけとは限りません。ドメインの名前解決が想定した経路を通っていない可能性もあります。システムDNS、アプリ独自の暗号化DNS、コア内蔵DNSを区別し、ルーティングによって名前解決が行われるかを確認しましょう。以下はコアのDNSサーバー設定を簡略化した例で、すべてのアプリの問い合わせが処理されるという意味ではありません。変更前後のログとアクセス結果を比較し、名前解決の設定は一度に1か所だけ変更してください。リモートDNSを使う場合は、DNSサーバーへの接続自体が確立できることも確認し、依存関係のループを避けましょう。
{
"dns": {
"servers": [
"1.1.1.1",
"8.8.8.8"
]
}
}
DNS設定のリファレンスを見る →
TUNによる通信制御とループバックのリスク
TUNは仮想ネットワークインターフェースを使って通信を処理するため、より多くのアプリを対象にしたい場合に適しています。ただし、権限、ルーティング、DNSを連携させる必要があります。まず通常のプロキシ接続が使えることを確認してから、クライアントでTUNを有効にし、仮想インターフェースとシステムルートの変化を確認してください。以下はローカル接続テスト用のSOCKSインバウンドであり、TUNを有効にする設定ではありません。TUNの実装と設定形式はクライアントの構成要素によって異なるため、このJSONを仮想ネットワークインターフェースの設定としてそのまま使うことはできません。通信が切れたら、まずTUNを無効にしてログを保存してから原因を調べましょう。
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
}
]
}
TUNと通信制御の説明を見る →
最初のエラーから原因の範囲を絞る
コアが起動できない問題と、接続後にタイムアウトする問題は発生段階が異なるため、分けて対処します。同じ起動中に最初に現れたエラーを見つけ、設定の構文、ポートの競合、フィールドの互換性を確認してから、リモート接続とTLSハンドシェイクを調べましょう。再現時に一時的にログレベルを上げると、問題の把握に役立ちます。調査後は通常のレベルに戻し、不要な出力を減らしてください。以下のwarning設定では警告とエラーを確認できます。ログを共有する前に、サブスクリプションURL、認証情報、実際のアドレスを削除し、エラーの種類と前後の記録だけを残しましょう。
{
"log": {
"loglevel": "warning"
}
}
ログと設定のトラブル対処を見る →