config.json / outbounds 抜粋
サブスクリプションは接続設定をまとめて取得するためのもので、グループはクライアント上で取得元を区別するために使います。まずグループを作成し、サブスクリプションURLを入力して更新します。取得した内容を現在のクライアントで解析できるか確認してください。更新後は、リストに項目が表示されたかだけでなく、ノード名、プロトコル、トランスポートの各項目も確認しましょう。グループ名と自動更新間隔はクライアントの設定であり、共通のコア設定項目ではありません。下の例はインポート後に生成される可能性があるアウトバウンド設定です。リモート接続に必要な認証情報は含まれていないため、この例だけではプロキシ接続できません。複数の取得元を整理する場合は、フィルターを設定し、元のグループも残しておきましょう。
{
"outbounds": [
{ "tag": "direct", "protocol": "freedom" },
{ "tag": "block", "protocol": "blackhole" }
]
}
config.json / routing
ルーティングはルールの順序に従って、通信に使用するアウトバウンドを決定します。通常は先に一致したルールが適用されます。まずプライベートアドレスを処理し、次に明示的なドメインやアドレスのルールを追加し、最後にどのルールにも一致しない通信の既定の経路を確認します。ルール内のアウトバウンドタグは、アウトバウンド一覧のタグと完全に一致させてください。一致しないと、ルールがあっても期待どおりに動作しません。下の例では、プライベートアドレスを直接接続のアウトバウンドに送ります。この設定には対応する地理データファイルが必要です。グローバルモードの切り替えと違い、ルールによる振り分けではLANへのアクセス経路を保てますが、名前解決のタイミングやルールの適用範囲も確認する必要があります。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}
config.json / log
コアはクライアント名だけで選ぶのではなく、接続パラメーターに合わせて選択してください。まずプロトコル、トランスポート方式、安全性に関わる設定を確認し、使用するコアが各項目に対応しているか確かめます。特定の拡張機能を使う場合、別のコアでも同じ設定をそのまま読み込めるとは限りません。切り替え前に現在の設定を保存し、切り替え後は起動ログと生成された設定を確認して、実際に動作しているコアを特定しましょう。下のログレベルは初期調査に利用できます。詳細度を一時的に上げた場合は、確認後に元へ戻してください。実行ログにはアドレスや接続情報が含まれる場合があります。共有前に機密情報を取り除きましょう。
{
"log": {
"loglevel": "warning"
}
}
config.json / inbounds / SOCKS
システムプロキシが適用されるのは、システムのプロキシ設定を参照するアプリだけです。すべての通信を処理する機能とは異なります。まずローカルのプロキシインバウンドで接続を確認し、その後TUNが必要か検討してください。TUNの利用可否はクライアント、関連コンポーネント、コア、OSの権限によって異なります。任意の設定にスイッチを追加するだけで使えるものではありません。下の例はローカルホストのみで待ち受けるSOCKSインバウンドで、アプリにプロキシアドレスを明示して使います。TUNの設定例ではありません。モードを切り替える際は、ほかのプロキシソフト、仮想ネットワークアダプター、DNS設定も確認してください。複数の仕組みが同時に通信を処理すると、ループが発生するおそれがあります。
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "auth": "noauth", "udp": true }
}
]
}
config.json / dns
DNS設定はアプリ、OS、コアの3つの層で確認する必要があります。クライアントにリゾルバーを設定しても、すべてのアプリの問い合わせがコアを経由するとは限りません。まずドメイン名がどこで解決されるかを確認し、次にリゾルバーへの通信経路が、まだ確立されていないプロキシ接続に依存していないか調べます。下の例はローカル環境で名前解決する基本的な書き方です。設定項目の位置を説明するもので、すべてのネットワークに適用できるとは限りません。IPアドレスではアクセスできるのにドメイン名では失敗する場合は、名前解決の結果とルーティング方針を照合してください。DNSサーバーを変更するだけでなく、問い合わせがコアに届いていない可能性も確認しましょう。
{
"dns": {
"servers": ["localhost"]
},
"routing": {
"domainStrategy": "AsIs"
}
}
config.json / inbounds / LAN
LAN内で共有するには、待ち受けアドレス、OSのファイアウォール、ほかの端末のプロキシ設定がすべて正しく動作する必要があります。ループバックアドレスのみで待ち受けている場合、ほかの端末からは接続できません。すべてのインターフェースで待ち受ける場合は、接続元を制限してください。下の例は認証付きHTTPインバウンドの一部です。認証情報は説明用のダミー値なので、使用前に必ず変更してください。ほかの端末にはループバックアドレスではなく、PCのLAN内アドレスを入力します。共有は信頼できるネットワーク内でのみ行い、プロキシポートをインターネットに公開しないでください。共有が不要になったら待ち受けを停止するか、ローカルホストのみの待ち受けに戻しましょう。
{
"inbounds": [
{
"tag": "lan-http",
"listen": "0.0.0.0",
"port": 10809,
"protocol": "http",
"settings": {
"accounts": [
{ "user": "example-user", "pass": "your-password" }
]
}
}
]
}