Global Routing
Config・Proxy・Direct：3つの処理モード
HomeのGlobal Routingから設定します。リクエストの処理方法を決める機能であり、接続のオン／オフやサーバーの提供を行うものではありません。
| モード | 処理方法 | 用途 | 確認するポイント |
|---|---|---|---|
設定 · Config | 現在の設定ファイルにあるルールに基づいて処理方法を選びます。 | ドメインやアドレスなどの条件で、通常の通信を振り分けます。 | 有効な設定、ルールの順序、最終的な処理方法を確認します。 |
プロキシ · Proxy | 通信をプロキシ経由で処理します。システム側の例外設定なども考慮が必要です。 | 現在のサーバーで目的のリクエストを処理できるか、一時的に確認します。 | 選択中のサーバーと接続パラメータを確認します。 |
直接接続 · Direct | 通信を直接接続で処理します。 | ローカルネットワークを比較したり、プロキシ経由の問題かどうかを切り分けたりします。 | 現在のネットワークから、対象に直接接続できることを確認します。 |
選び方と確認方法
HomeでGlobal Routingを開き、必要なモードを選択してから、戻って接続スイッチの状態を確認します。通常のルール振り分けにはConfigを選び、Config画面で実際に有効な設定ファイルを確認してください。ファイルを読み込んでも有効化していない場合や、別のファイルを編集した場合は、変更が反映されないことがあります。
問題の切り分けには、ProxyとDirectで同じ宛先を一時的に比較できます。元のモードは必ず記録してください。Proxyでは使えるのにConfigでは失敗する場合、まず該当ルールとポリシーを確認します。Directでは使えるのにProxyで失敗する場合は、選択中のサーバー、プロトコルのパラメータ、プロキシ経路を確認します。この比較だけで原因を断定することはできません。
確認後は、元の用途に合ったモードに戻します。Proxyをあらゆるルールの問題を解決する恒久的な代替手段にしないでください。また、Directでも接続中と表示されることがありますが、リクエストがプロキシを経由するとは限りません。接続状態とルーティングの判断は別のものです。
[Rule]
ルールの種類・照合順序・ポリシー
ルールは「何に一致するか」、ポリシーは「どのように処理するか」を定めます。HomeからConfigを開き、現在の設定ファイルのルール編集画面で確認できます。
まず照合条件を確認
DOMAINは完全一致のドメイン名、DOMAIN-SUFFIXはドメイン名とそのサブドメインに一致します。DOMAIN-KEYWORDはドメイン名に含まれるキーワードで照合します。キーワードの適用範囲は広くなりやすいため、関係のないドメインにも一致しないか、追加前に確認してください。
IP-CIDRとIP-CIDR6は、それぞれ異なる種類のIPアドレス範囲を指定します。GEOIPはIPアドレスの地域分類を使用し、判定結果は関連データに左右されます。USER-AGENTはリクエストから取得できる情報に基づくため、すべての接続を識別できるわけではありません。
次に処理ポリシーを確認
DIRECTは直接接続、PROXYはプロキシ経由、REJECTは一致したリクエストの拒否を表します。ポリシー名はサーバーアドレスではありません。カスタムポリシーグループを使う場合は、グループ内で実際に選択されている項目も確認してください。
ルールは通常、上から順に照合されます。具体的な条件は、それを上書きする可能性のある広範な条件より前に配置します。FINALは、それ以前のルールに一致しなかったリクエストを処理するため、分類条件の代わりにせず、ルールの末尾に置きます。
ルールを変更する手順
まず現在の設定をバックアップし、Configで使用中のファイルを開きます。ルールを追加するときは、種類、照合内容、ポリシーを順に確認します。保存後、ファイルが有効になっていることをもう一度確認してください。以下は構文の例であり、完全な設定ではありません。また、例示したドメインで利用可能なサービスがあることを示すものでもありません。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
DOMAIN-SUFFIX,ads.example.net,REJECT
FINAL,PROXY例では完全一致のドメインルールをサフィックスルールより前に置いているため、api.example.comには優先してPROXYが適用されます。確認時は、ページが最終的に開いたかだけでなく、新しいリクエストの照合記録を確認してください。キャッシュ、既存の接続、ページ内の別ドメインへのリクエストが結果に影響することがあります。一つのドメインの問題を解決するために、広範なルールを一度に複数追加しないでください。
設定ファイルのセクション解説を読む →SERVER
サブスクリプションとサーバーの管理
Homeではサーバーの確認と選択を行い、Add Serverでは接続情報を追加・入力します。サーバーのサブスクリプションとConfigのルール設定は別のものです。
お持ちの情報を読み込む
サブスクリプション情報は、ご利用のサービス提供元から入手してください。読み込む前に、更新可能なサーバーサブスクリプションのURL、単一サーバーの共有リンク、設定ファイルのURLのどれなのかを確認します。サーバーのサブスクリプションは、Add ServerでSubscribeを選んで入力できます。アプリにクリップボードやScan QR Codeの機能がある場合も、認識された情報の種類を確認してください。ブラウザで開けるURLだからといって、アプリが読み込めるサブスクリプションデータとは限りません。
サーバーを手動で追加する場合は、Add Serverで実際に使うプロトコルを選び、サーバーアドレス、ポート、認証情報を順に入力します。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2など、プロトコルによって必要な項目は異なります。同じパラメータ一式を別のプロトコルにそのまま適用しないでください。転送方式、TLS、ホスト名などの追加項目も、入手した情報に合わせます。
更新・選択・バックアップ
読み込み後はHomeに戻り、想定した項目が一覧に表示されていることと、接続に使うサーバーが選択されていることを確認します。サブスクリプションの更新は、通常、そのサブスクリプションに含まれるサーバー一覧を更新する操作です。Global Routingの切り替えや、Configのルールファイルの更新とは異なります。サブスクリプション内の項目を手動で調整した場合、次回の更新で関連項目が上書きされることがあります。残しておきたい情報は別途保存してください。
サブスクリプションの更新に失敗したら、URLが完全か、余分な空白がないか、有効期限が切れていないか、ログイン画面やエラーメッセージが返っていないかを確認します。バックアップを取らずにグループ全体を何度も削除しないでください。サブスクリプションURLや共有リンクには認証情報が含まれる場合があります。スクリーンショット、ログ、問い合わせ資料では必ず隠してください。当サイトではサーバーやサブスクリプションの提供・販売・推奨は行っていません。
On Demand
条件に応じて接続を開始
On Demandは、設定した条件に基づいてシステムに接続を開始させる機能です。ドメインごとに適用するルールを選ぶ機能ではありません。
設定場所と有効化の手順
SettingsでOn Demand関連の項目を探し、現在利用できるネットワーク環境に合わせて接続条件を設定します。自動接続を有効にする前に、手動接続でサーバー、DNS、ルールが正常に動作することを確認してください。先に有効にすると、自動再接続によって元の問題が繰り返され、原因の特定が難しくなることがあります。
設定後は、普段使うネットワークの状況ごとにテストします。指定したネットワークへの接続・切断、画面ロック後の復帰、Wi-Fiとモバイル通信の切り替えなどで、想定どおり接続するか確認してください。スイッチがオンかどうかだけでは判断できません。システムの動作、ネットワークの利用状況、ほかのVPN設定も実際の動作に影響するため、On Demandを常に同じ接続状態を保つ機能と考えないでください。
一時停止してから確認する場合
手動で接続を切っても再接続される場合は、まずOn Demandの条件を確認し、次にシステム側の関連VPN設定を確認します。Directで比較したり設定を変更したりする間は、自動接続を一時停止するとテスト状態が変わるのを防げます。確認後に再び有効にし、接続するネットワークと接続しない状況を記録してください。ルールの振り分けは引き続きGlobal Routingと現在の設定によって決まります。
Data
通信量の統計とリクエストの確認
Dataでは、アプリに記録された通信量を確認できます。接続状況の把握に役立ちますが、サブスクリプションのアカウント情報や通信事業者の利用明細に代わるものではありません。
まず統計の範囲を確認
Dataを開いたら、現在の画面に表示されている集計範囲、期間、分類を確認します。画面によって累計量、特定の接続中の通信、処理経路ごとのデータなど、表示内容が異なる場合があります。比較するときは同じ条件にそろえてください。特定ドメインの通信量には、ページ内のリソース、バックグラウンド更新、アプリの自動リクエストが含まれることもあります。ドメイン名だけで操作内容を判断しないでください。
新しいルールを確認する場合は、まず現在の統計を記録し、テスト対象一つだけにアクセスします。接続記録とあわせて、新たな通信や適用されたポリシーを確認してください。統計をリセットする機能がある場合は、必要なデータを保存してから実行します。統計を消去しても、既存のサブスクリプションの利用可能量は変わらず、接続の問題も解決しません。
統計だけで結論を出さない
通信量の合計が増えたことから分かるのは、データ転送が発生したということだけです。すべてのリクエストが想定どおりに振り分けられた証明にはなりません。暗号化のオーバーヘッド、再送、接続に伴う通信、集計範囲の違いにより、アプリ側の数値とアカウント側の記録が一致しないことがあります。通信量の異常を調べるときは、発生時刻、リクエスト先、バックグラウンド動作を照らし合わせ、原因を絞り込んでください。特定の設定が原因だと決めつけないようにします。
Settings
DNS・テスト方法・ショートカット・同期
Settingsではアプリ全体の動作を設定します。関連項目が設定ファイルで定義されている場合もあります。有効な設定を確認するには、現在適用中のConfigも確認してください。
DNS：名前解決と接続の失敗を切り分ける
DNSはドメイン名をIPアドレスに変換します。関連設定はSettingsにある場合と、Config内の[General]パラメータ（dns-serverなど）で定義される場合があります。変更前に現在どの方法で名前解決しているかを確認してください。一か所を変更しただけで、すべてのリクエストに新しい設定が適用されたとは限りません。
Connectivity Testの結果が出てもWebページを開けない場合は、サーバーだけを変更せず、ドメインの名前解決、実際のリクエスト経路、TLSも確認します。設定をバックアップしたうえで、適用範囲を把握してからDNS項目を一つだけ変更し、同じドメインで再テストしてください。DNS、ルーティングモード、サーバーを同時に変更すると、復旧しても何が有効だったのか分からなくなります。
Test Method：テスト条件をそろえる
SettingsのTest Methodで、Connectivity Testに使用する方法を確認します。テスト方法によって確認できる範囲が異なり、トランスポート層で到達できてもWebページのリクエスト全体が成功するとは限りません。テスト先、現在のネットワーク、サーバーの負荷、リクエスト方法が結果に影響します。複数のサーバーを比較する際は、テスト方法とテスト先をそろえてください。
テスト先の入力が必要な場合は、アクセス可能で、検証に適していると確認できる宛先を使います。テストに異常が出たら、まずテスト先自体にアクセスできるかを確認し、その後サーバー設定を調べてください。一度の結果だけで長期的な安定性を判断したり、テスト値を実際のコンテンツ読み込み速度と同一視したりしないでください。
Today Widget：ショートカットとして使う
Today Widgetは、システムが対応する情報の確認や操作に使うショートカットです。まずSettingsでアプリの関連項目を確認し、現在のシステムのウィジェット管理方法に従って追加してください。表示内容や操作できる項目は、実際のシステムとアプリにより異なります。ウィジェットを独立した別の設定として扱わないでください。
ショートカットから操作した後、接続状態や選択中のサーバーが分からない場合はHomeに戻って確認します。ウィジェットの表示には更新の遅れが生じることがあります。アプリ内の状態と実際のリクエスト結果をあわせて判断し、古い表示だけを見てスイッチを何度も切り替えないでください。
iCloud：同期内容を確認してから復元
SettingsでiCloud関連の同期・読み込み項目を確認し、システム上でアプリにiCloudへのアクセスが許可されていることを確かめます。同期されるデータの範囲は、現在の画面の説明に従ってください。アプリをインストールしただけで、サーバー、設定、すべての環境設定が自動的にそろうとは限りません。
デバイスを変更する前に、管理できる場所へ設定のバックアップを保存してください。別のデバイスに復元した後は、サーバー一覧、有効なConfig、Global Routing、On Demandの条件を一つずつ確認します。App Storeの購入履歴とiCloud上のアプリデータは別のものです。アプリを再入手しても接続パラメータが復元されるわけではありません。認証情報を含むバックアップは、アクセス権のある場所にのみ保存してください。
Diagnostics
一度に一つずつ、順番に診断
Diagnosticsと接続記録から、問題解決の手がかりを得られます。再現できる状況を記録し、症状に合ったテストを行ってから、結果に基づいて設定を調整します。
有効な診断結果を集める方法
SettingsでDiagnosticsを開き、現在利用できるツールでネットワーク、名前解決、接続状況を確認します。開始前に、使用中のネットワーク、選択中のサーバー、Global Routing、有効な設定、失敗する具体的な宛先を記録してください。リクエストをもう一度発生させ、そのリクエストに対応する結果を確認します。以前のエラーを現在の状態と取り違えないようにしてください。
- ローカルネットワークを確認。まず基本的なネットワーク接続が利用できるか、ネットワークへのログインが必要かを確認します。
- サーバーパラメータを確認。アドレス、ポート、プロトコル、認証情報、追加の転送設定が一致しているか確認します。
- ルーティングと名前解決を確認。現在のモード、対象に一致するルール、DNSの結果を確認し、名前解決と接続の問題を分けて判断します。
- 一項目を変更して再テスト。同じ宛先とテスト方法を使い、変化を記録します。効果がなければ元の値に戻してから、次の項目を試します。
保護が必要な情報
診断記録には、ドメイン名、アドレス、リクエスト時刻、サブスクリプション情報、認証パラメータが含まれる場合があります。書き出しやスクリーンショットの前に、機密情報を一つずつ隠し、問題の特定に必要なエラー表示と設定項目名だけを残してください。問題に関係のない詳細ログを、記録を増やす目的で長期間保存しないでください。
特定のネットワークやドメインを使う場合、またはサブスクリプションを更新した後だけ問題が起きるなら、その条件を記録してください。「接続できない」とだけ伝えるより、原因を絞り込む手がかりになります。症状に応じた確認を続ける場合はトラブル診断ページへ、接続手順を最初から確認する場合は、すべての設定を消去する前に、はじめにへ戻ってください。