01 プロキシグループの高度な使い方
プロキシグループはノードのグループがどのように自動または手動で選択されるかを決定します。適切なタイプを選ぶことで日常使用の安定性が大きく向上します。
| 型 | 動作 | 適用シーン |
|---|---|---|
| select | 完全に手動で選択し、自動切り替えは行わない。 | 長期的に特定のノードを固定して使いたい場合、または回線を手動で制御したい場合。 |
| url-test | 定期的に速度を測定し、遅延が最も低いノードに自動的に切り替える。 | 日常使用の第一選択。手動操作なしで比較的良い回線を利用できる。 |
| fallback | 順番にノードを試し、現在のノードが使えなくなった時だけ次に切り替える。 | メインとして使いたいノードがあり、障害発生時のみ切り替えたい場合。 |
| load-balance | 1つのノードだけでなく、複数のノード間で接続を分散させる。 | 各ノードの帯域幅が限られている場合に、帯域幅を合算したり負荷を分散させたい場合。 |
| relay | 複数のノードを順番に連結し、通信が各ホップを順に経由する。 | 匿名性を高めたり特定の制限を回避するために多段跳躍が必要な場合。速度は低下する。 |
# 組み合わせの例:外側はselectで地域を手動切り替え、内側はurl-testで自動最適選択
proxy-groups:
- name: "PROXY"
type: select
proxies: ["HK-AUTO", "SG-AUTO", "JP-AUTO"]
- name: "HK-AUTO"
type: url-test
proxies: ["HK-01", "HK-02"]
url: "http://www.gstatic.com/generate_204"
interval: 300ヒント:プロキシグループは互相にネストして参照できます(上記例のように)。これは「地域を手動選択+最適ノードを自動選択」の2層構造を構築する際によく使われる書き方です。全フィールドの説明は設定ドキュメントのproxy-groupsフィールドをご覧ください。
02 TUNモードの詳しい解説と設定
TUNモードはシステムのネットワーク層に仮想ネットワークアダプタを作成し、デバイス上のほぼすべての通信を処理します。システムプロキシモードと比べて互換性が高く、特にシステムプロキシ設定に従わないゲームや一部のクライアントソフトに有効です。
# TUNモードを有効にする最小構成
tun:
enable: true
stack: gvisor
auto-route: true
auto-detect-interface: true
# TUNモードはFake-IPと組み合わせて有効化するのがおすすめ
dns:
enable: true
enhanced-mode: fake-ipOSごとの認証方法
| OS | 認証方法 |
|---|---|
| Windows | クライアントを管理者権限で実行してください。初回有効化時にTUN/TAPドライバが自動でインストールされます。 |
| macOS | 初回有効化時にネットワーク拡張機能またはVPN設定のインストールが求められるので、システム設定で許可を確認してください。 |
| Android / iOS | システムがVPN接続の許可プロンプトを表示するので、手動で許可をタップしてください。 |
| Linux | root権限で実行するか、バイナリファイルにCAP_NET_ADMIN権限を設定する必要があります。 |
ヒント:TUNモードを有効にしてもネットに繋がらない場合は、まず
auto-routeとauto-detect-interfaceが両方とも有効になっているか確認してください。それでも解決しない場合はstackをgvisorからsystemに切り替えて、ネットワークスタックの互換性問題かどうかを確認してみてください。03 Fake-IPとDNSの詳細設定
Fake-IPはコアがDNS解決の段階で仮想のローカルアドレスを返し、実際の接続先の判定は通信がコアを通過する際に行われるようにする仕組みです。これによりドメインマッチ系のルール(DOMAIN-SUFFIXなど)がより正確に機能し、TUNモードでも推奨される組み合わせです。
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost.ptlogin2.qq.com"
nameserver:
- 223.5.5.5
- 119.29.29.29
fallback:
- tls://1.1.1.1:853
- tls://8.8.8.8:853フィールドの説明
| フィールド | 説明 |
|---|---|
| fake-ip-range | Fake-IPで使用する仮想アドレス範囲。通常は実際のLANアドレスとの競合を避けるためプライベートアドレス範囲を使う。 |
| fake-ip-filter | Fake-IPを使用しないドメインのホワイトリスト。LAN内デバイスやログイン認証などのシーンでは除外が必要になることが多い。 |
| nameserver | 通常の解決に使用する上流DNS。中国本土向けアドレスには中国本土の解決ノードの使用を推奨。 |
| fallback | nameserverの解決結果が汚染と判定された場合(返されたIPが想定した地域にない場合など)に使用するバックアップの暗号化DNS。 |
ヒント:LAN内のルーター管理画面や、LAN直接接続が必要な一部のログイン認証サービスは、誤ってプロキシ経由になってアクセスできなくなることを避けるため、
fake-ip-filterに追加することをおすすめします。04 Rule Providerルールセットの高度な使い方
ルールセットは大量のルールをリモートファイルにまとめて管理し、クライアントが定期的に取得・更新することで、手動で1件ずつ記述・維持する手間を省きます。異なるbehaviorのルールセットを組み合わせることで、継続的に更新可能な完全な分流プランを構築できます。
rule-providers:
direct-domain:
type: http
behavior: domain
url: "https://example.com/direct-domain.txt"
path: ./ruleset/direct-domain.yaml
interval: 86400
private-ip:
type: http
behavior: ipcidr
url: "https://example.com/private-ip.txt"
path: ./ruleset/private-ip.yaml
interval: 86400
rules:
- RULE-SET,private-ip,DIRECT
- RULE-SET,direct-domain,DIRECT
- MATCH,PROXYヒント:更新間隔(
interval)は短く設定しすぎないことをおすすめします。ルールセットは頻繁に変わるものではなく、あまりに頻繁な取得は不要な通信を増やすだけです。詳しい選び方はブログ記事「Rule Providerルールセット完全ガイド」をご覧ください。05 パフォーマンスと安定性の最適化提案
1
ルールリストをシンプルにするルールの数が多いほど、マッチングにかかるコストが大きくなります。使用頻度の低いルールはルールセットに統合し、頻度の高いカスタムルールだけを少数ローカルリストに残しましょう。
2
速度測定の間隔を適切に設定するurl-testのintervalを短くしすぎると余分な通信とCPU負荷が増え、長すぎるとノード異常時の切り替えが遅くなります。300〜600秒程度がバランスの取れた範囲です。
3
不要な多段連結を避けるrelayタイプによる多段ノード連結は遅延を大きく増加させるため、本当に必要な場合(多重跳躍が必要な場合など)のみ使用してください。
4
必要に応じてログレベルを設定する日常使用ではlog-levelをwarningまたはerrorに設定することをおすすめします。トラブルシューティング時のみ一時的にdebugに切り替え、長期的に大量のログファイルが生成されるのを避けましょう。
5
コアとクライアントのバージョンを定期的に確認する新バージョンには通常パフォーマンスの最適化やプロトコル互換性の修正が含まれています。ダウンロードページで定期的に更新の有無を確認することをおすすめします。
もっと詳しく知りたいですか?
設定ドキュメントセンターでは完全なフィールド参照を、よくある質問では頻出のトラブルシューティングを、用語辞典では専門用語の理解をサポートしています。