Shadowrocket
使い方・完全ガイド

01 / ACQUIRE

入手とインストール：プラットフォームと入手元を確認

設定を始める前に、「アプリのインストール」と「接続サービスの準備」を分けて考えます。Shadowrocketはクローズドソースの商用アプリです。インストールが完了しても、プロキシ接続やルール処理を行うアプリが端末に用意されるだけで、利用可能なサーバーが自動的に作られるわけではありません。iPhone / iPad版はApp Storeで2.99米ドルの買い切り、Mac / Windows / Android / Linux版は無料です。既存のSubscribeの有効期限、アカウント状態、通信量制限は提供元の条件によるもので、アプリの入手方法とは別のものです。

iPhone / iPad：App Storeの掲載内容を確認

ダウンロードページのiPhone / iPad用リンクからApp Storeを開き、アプリ名Shadowrocket、デベロッパ名Shadow Launch Technology Limited、公式アイコン、アプリID 932747118を確認してください。検索結果の名前だけで判断しないでください。名前が似ていても同じアプリとは限りません。システム要件はApp Storeの掲載内容を確認してください。互換性については、古い記事の記載よりストアの表示を優先してください。

App Storeで見つからない場合は、まずApple IDの国または地域と、その地域でのアプリ提供状況を確認してください。中国本土のApp Storeではこのアプリを提供していません。端末の表示言語やシステムの地域を変更しても、購入アカウントのストア地域は変わりません。アカウントの地域を変更する場合は、残高、既存のSubscribe、支払い方法に関する制限をアカウント設定で確認してください。影響を理解しないままアカウントを何度も切り替えたり、検索結果に表示されないことをインストールファイルの破損と判断したりしないでください。

PC・Android：対応するインストーラーを選ぶ

その他のプラットフォーム版は全プラットフォームのダウンロードページから入手できます。インストーラーは本サイトの/dl/shadowrocket/から提供しています。Macでは「このMacについて」を開き、Appleシリコン搭載機ならAppleシリコン版dmg、Intelプロセッサ搭載機ならIntel版dmgを選びます。Windowsではページに掲載されている64ビット版を、Androidではarm64版を選び、現在のブラウザーまたはファイル管理アプリからのインストールが許可されていることを確認してください。拡張子が似ていることだけでアーキテクチャを判断しないでください。

デスクトップ版とAndroid版のインストーラーにはコード署名がなく、初回起動時にシステムがブロックする場合があります。Macで「開発元を検証できない」と表示された場合は、本サイトから入手したファイルであることを確認したうえで、「システム設定」の「プライバシーとセキュリティ」から「このまま開く」を選択してください。WindowsでSmartScreenの警告が表示された場合も、入手元を確認してから「詳細情報」を開き、「実行」が表示されるか確認します。これらは該当ファイルに対する判断です。システム全体の保護機能を無効にする必要はありません。組織の管理下にある端末では、管理者の方針に従ってください。

Macで「破損しているため開けません」と表示された場合は、不完全なダウンロードを削除し、正しいアーキテクチャのファイルを再入手してください。アプリがApplicationsに配置され、入手元に問題がないことを確認してから、必要な場合に限り、以下のコマンドでアプリの隔離属性を解除します。このコマンドは対象アプリの隔離処理を変更します。入手元が不明なファイルには使わず、パスをディスク全体に変更しないでください。詳しくはMac・Windowsのインストールガイドをご覧ください。

xattr -cr /Applications/Shadowrocket.app

Linux：パッケージ形式と実行権限

Debian / Ubuntuでは通常debを使い、依存関係の処理はaptに任せます。Fedora系ではrpmとdnfを組み合わせます。AppImageは実行権限を付与してから起動してください。コマンドに指定するローカルファイル名は、実際にダウンロードしたファイル名と一致させます。例からパッケージ名を推測しないでください。ダウンロードの不完全、アーキテクチャの不一致、実行時依存関係の不足はそれぞれ別の問題です。ターミナルの出力を個別に確認してください。手順の詳細はLinuxインストールガイドをご覧ください。

インストールが完了してから次の章へ進んでください。アプリを正常に起動できる前に、接続情報をまとめてインポートしないでください。機種変更や再インストールの場合、iPhone / iPadでは購入時のアカウントで購入済み項目を確認します。その他のプラットフォームでは、本サイトから対応するインストーラーを再度ダウンロードしてください。古いインストーラーを保管するより、既存設定のバックアップを残すことが重要です。サーバー情報、ルール、ローカル設定は、アプリを再ダウンロードしても自動的には復元されません。

02 / PERMISSIONS

初回起動と権限：確認できる状態を整える

Shadowrocketを初めて開いたら、まずHomeにサーバーが登録されているか、Global Routingで何が選択されているか、接続スイッチがオフになっているかを確認します。この段階でSettingsをすべて変更する必要はありません。再現しやすい開始条件は、システムのネットワークで通常のWebページを開けること、アプリが未接続であること、ほかに動作中のVPN設定がないことです。こうしておくと、後で問題が起きた際に、元のネットワークの不具合かアプリの設定の問題かを切り分けやすくなります。

VPN構成の許可が意味すること

iPhone / iPadで初めて接続するとき、システムからVPN構成の追加を求められ、端末のパスコードや生体認証での確認が必要になる場合があります。この許可により、アプリはシステムのネットワーク拡張を通じて対象の通信を処理できます。接続サービスを購入したことを意味するものでも、すべてのリクエストが必ずリモートサーバーを経由することを示すものでもありません。リクエストがPROXYとDIRECTのどちらを通るかは、Global Routingと現在の設定によって決まります。システムの確認画面に表示されたアプリ名を確認してから、端末上で許可してください。

許可を拒否したことがある場合は、アプリに戻って接続を再試行し、システムの案内を確認してください。システムの確認画面が表示されないときは、設定でVPNの状態を確認し、端末が管理ポリシーの制限を受けていないか調べます。最初からネットワーク設定をすべて削除しないでください。保存済みのWi-Fi情報やほかの接続設定も消える可能性があります。まずアプリが権限を要求できるか、VPN構成を書き込めるかを確認し、必要な場合に限って古いShadowrocketのVPN構成を削除して再度許可してください。

ネットワーク拡張機能どうしの影響を確認

端末にほかのVPN、企業ネットワーク接続、ネットワークフィルター、システム管理機能が設定されている場合があります。トラブルシューティングでは、同じ通信を処理する機能を先に停止し、Shadowrocketだけでテストしてください。併用できるかどうかはシステムの仕組みと設定によって異なり、アイコンだけでは判断できません。企業の構成プロファイルを削除すると業務ネットワークに影響する場合があります。管理対象端末では、組織のポリシーをテスト目的で削除せず、管理者に相談してください。

システムのステータスバーにVPNアイコンが表示されても、確認できるのはシステムに該当するトンネル状態があることだけです。サーバー認証、DNS、接続先のWebサイト、ルールがすべて正常とは限りません。反対に、ホーム画面に戻ってアプリが前面に表示されなくなっても、接続が終了したとは限りません。単独のアイコンを接続成功の根拠にせず、Homeの接続状態と実際のリクエスト記録を合わせて確認してください。

カメラ・写真・ローカルネットワークの権限

Scan QR Codeを使う場合、カメラ権限はQRコードの読み取りに使います。画像から情報を読み込む場合は、写真へのアクセスも必要になることがあります。該当するインポート方法を使うときだけ権限を設定してください。QRコードを使わなくても、Add Serverに手動入力できます。写真へのアクセスを許可するときは、インポートに必要な範囲を選んでください。QRコードに認証情報が含まれている場合があります。写真に保存したり他人に共有したりするときは注意してください。

ローカルネットワークへのアクセスを求められたら、LAN機器や関連機能へのアクセスが本当に必要かを確認してください。権限とルーティングポリシーは別の仕組みです。ローカルネットワークへのアクセスを許可しても、すべてのLANアドレスが自動的にDIRECTになるわけではありません。ルールが正しくても、OSが明示的に拒否したアクセス権限を回避することはできません。LAN機器に接続できない場合は、権限、IPアドレス、サブネット、現在のWi-Fiでクライアント間通信が制限されていないかを個別に確認してください。

ネットワークの基準状態を保ち、変更は一度に一つ

初回設定の前に、Wi-Fiとモバイルデータ通信のどちらを使っているか、Web認証が必要か、通常のWebページを直接開けるかを記録しておくと便利です。公衆Wi-Fiでは、クライアント接続前に認証ページでの手続きが必要なことがあります。Wi-Fiに接続済みと表示されても、インターネットにアクセスできるとは限りません。モバイルデータ通信では、アプリのネットワーク利用がシステムによって制限されていないか、データ通信が実際に使えるかも確認してください。

初回接続が成功するまではOn Demandをオフにし、複雑なDNSやほかの詳細設定を変更しないことをおすすめします。一度に一つの問題を扱い、まずアプリにシステム権限を許可し、次に有効性が確認できている情報を一組インポートし、最後に接続テストを行います。バックグラウンドに移動した後に状態が変わる場合は、ネットワーク切り替えやシステムの表示を記録し、複数のスイッチを同時に変更せず、メンテナンスの章で原因を確認してください。

この章の確認基準は、アプリが正常に起動すること、システムがVPN構成の追加を許可すること、基本ネットワークが利用できること、接続を手動で切断する方法が分かっていることです。権限が引き続きブロックされる場合は、FAQの「各プラットフォームのインストールと初回起動」から確認してください。権限の問題を解決しないままルールの調整に進まないでください。症状が似ていても、対処方法は異なります。

03 / CONNECTION MATERIAL

サーバーの追加とSubscribe：情報の種類を見分ける

この章では、自分で用意したSubscribeまたはサーバー情報があることを前提にします。受け取った情報が、単一サーバーのパラメーター、個別の共有リンク、QRコード、サーバー一覧を更新できるSubscribe URLのどれにあたるかを確認してください。いずれも文字列で表示される場合がありますが、用途は異なります。Subscribe URLをサーバーのアドレス欄に入力したり、共有リンク全体をパスワード欄に貼り付けたりしても、URLのように見えるからといって正しい設定に変換されるわけではありません。

Add Server：手元のパラメーターを一つずつ入力

手動で追加する場合は、Homeの追加メニューからAdd Serverを開き、サーバー側と同じプロトコルを選んでからアドレスとポートを入力します。アドレスにはホスト名またはIPを指定し、Webページのパスを独自に追加しないでください。ポートにはサーバー側から指定された値を使います。Remarkは端末上で識別するためのもので、認証には使われません。パスワード、UUID、鍵などの認証情報は変更せず、コピー時に余分な空白、改行、日本語の句読点が入っていないか確認してください。

プロトコル名を一致させるのは最初の確認にすぎません。同じプロトコルでも、トランスポート方式、TLS、SNI、パスなどが異なる場合があります。「サーバーから応答がある」ことだけを理由に、これらの項目を省略しないでください。SNIはTLSハンドシェイクで使う名前であり、自由に設定する備考ではありません。WebSocketのpathとHostにもそれぞれ用途があります。必要なパラメーターが手元にない場合は、元のサービス情報を確認してください。項目の誤りを隠すために証明書の検証を無効にしないでください。

共有リンクとQRコード：インポート後も確認

クリップボードからのインポートやScan QR Codeを使うと、手入力によるミスを減らせます。ただし、インポートに成功したことは、アプリが情報を解析できたという意味にすぎず、リモートサービスが現在も有効とは限りません。インポート後に項目の詳細を開き、プロトコル、サーバーアドレス、ポートが元の情報と一致するか確認してください。QRコードが圧縮されている、隠れている、複数の情報を含んでいる場合などは読み取れないことがあります。その場合は、同じぼやけた画像を繰り返しスキャンせず、鮮明な元画像を再入手するか、元のテキストを使ってください。

スキャン結果がSubscribe URLの場合は、単独のサーバーとしてではなくSubscribeとして保存してください。スキャン画面や項目の位置は画面変更により異なる場合がありますが、判断基準は情報の内容です。認証情報を含むQRコードを公開の認識サービスにアップロードしたり、共有リンク全体を公開の問い合わせに貼り付けたりしないでください。問題の確認ではプロトコル名と項目名だけを伝え、認証情報は隠してください。

Subscribe：サーバー一覧を更新

既存のSubscribeを追加する場合は、提供元から受け取った完全なURLを入力して保存し、更新を実行して結果を確認します。URLのパスやクエリパラメーターが認証に使われる場合があります。末尾のパラメーターを削除すると、リクエストが失敗することがあります。更新結果が空、認証エラー、形式を解析できない、ネットワークタイムアウトはそれぞれ異なる状態です。まずURLが完全で現在も有効かを確認し、次に基本ネットワークからアクセスできるかを確かめ、最後に内容がアプリで認識できるSubscribe形式かを確認してください。

初回更新後は、一覧に表示されたグループ名と識別しやすいサーバーのRemarkを記録してください。Subscribeの更新で項目が追加、削除、改名される場合があります。更新後の変化をすべてアプリの異常とみなさないでください。Subscribe由来のサーバーを手動で変更すると、次回の更新で上書きされる場合があります。パラメーターを固定したい場合は、分かりやすい名前を付けた独立項目を作り、元のSubscribeも残してください。似た情報が混在して、どれを選んだのか分からなくなるのを防げます。

サーバー、Subscribe、Configは別の階層

サーバー項目は接続先を示し、Subscribeは複数のサーバー項目の取得元を管理し、Configはトラフィックがどのルールに一致し、どのポリシーを使うかを決めます。サーバーを追加しただけでは、あらゆる用途に適したルールが用意されるわけではありません。Configをダウンロードしても、利用可能なサーバー認証情報が含まれているとは限りません。インポート後は、Homeで選択されているサーバーとConfigで現在有効な設定をそれぞれ確認してください。いずれかの一覧に項目があれば準備完了と判断しないでください。

最終的に、必要なのは有効な接続情報の一式、認識できる現在のサーバー、用途を把握しているConfigです。似たSubscribeやConfigを続けて何件もインポートしないでください。重複すると選択を間違えやすくなり、問題が起きた際に情報の入手元を特定しにくくなります。初回インポートだけ済ませたい場合は、クイックスタートに戻って手順を進めてください。この章は項目の確認と更新動作の確認に利用できます。

04 / GLOBAL ROUTING

Global Routing：3つの処理モードを理解する

Global Routingでは、トラフィック全体をどの方針で処理するかを選びます。設定、プロキシ、直接接続は、画面上のConfig、Proxy、Directにそれぞれ対応します。3種類のサーバーやサービスのランクを示すものではありません。ここで選択を変えると、リクエストがルールに従うか、プロキシを使うかが変わります。ルールを調整する前に現在のモードを確認してください。同じConfigでもモードによって動作が異なり、ルールが反映されていないように見えることがあります。

Config、Proxy、Directの違い

細かな振り分けにはConfigがよく使われます。ルールのPROXYは通常、Configで定義されたプロキシポリシーまたは現在のプロキシポリシーを指します。DIRECTは直接接続、REJECTは一致したリクエストの拒否を表します。ルールで使うポリシー名が、実際のConfig内で対応していることを確認してください。任意のRemarkを有効なポリシーとして扱うことはできません。Proxyはルール一致の影響を切り分けるのに使えますが、パスワード、TLS、リモートサービスの問題を解決するものではありません。

Directも、アプリを終了した状態で行う基準テストの代わりにはなりません。アプリがDNSなどのネットワーク処理に引き続き関わる場合があるためです。問題がシステムネットワーク自体にあるか確認するときは、アプリを完全に切断してから同じ接続先にアクセスしてください。比較時はネットワークとURLを同じにし、なるべく近い時間にテストします。Wi-Fiを切り替えながらモードも変えると、どの変更が結果に影響したのか判断できません。

ルールは上から順に評価され、先に一致したルールが適用される

ルールファイルでは並び順が実際の動作に影響します。通常、より具体的なドメイン条件を範囲の広い条件より前に置き、最後にFINALをフォールバックとして配置します。次の例は構文と順序を説明するものです。指定したドメインのサフィックスはPROXY、LANアドレスは直接接続、GEOIP,CNに一致するアドレスは直接接続し、それ以外はPROXYにします。すべてのネットワークに適用できる完成済みConfigではありません。利用時は自分のサーバーとポリシー定義を確認してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAINは特定のドメインに一致します。DOMAIN-SUFFIXはそのドメインとサブドメインに使います。DOMAIN-KEYWORDはドメイン内のキーワードで照合するため、対象範囲が広く、意図しないサイトにも一致することがあります。IP-CIDRとIP-CIDR6はアドレス範囲に対応します。GEOIPはWebページの言語やサイトのブランドではなく、IPアドレスの地域情報に基づきます。ルールの種類を選ぶときは、短そうな書き方を選ぶのではなく、「手元にある根拠はドメインか、アドレスか」を確認してください。

ドメインルール、名前解決、接続記録を合わせて確認

同じWebページでも、本文、画像、ログイン、APIが複数のドメインを使うことがあります。トップページのドメインだけにルールを設定した場合、一部のリソースが別のポリシーを通るのは珍しくありません。リクエスト記録で読み込めなかったリソースの接続先を確認してから、正確なルールを追加してください。範囲の広いキーワードでページ全体をカバーすると変更は少なくて済みますが、無関係なドメインまでプロキシ対象になる可能性があります。

アドレスルールは一致のために名前解決が必要になることがあります。例のno-resolveは、そのアドレスルールがドメイン名の名前解決を能動的に開始する動作を制限するもので、すべてのDNSを無効にするものではありません。DNSキャッシュ、アプリが再利用する既存接続、接続先が複数のアドレスを使うことなどが確認結果に影響します。ルールを変更した後はテストリクエストを再送してください。必要であれば接続先のアプリを終了して再起動し、変更前に作られた接続を変更後のConfigの判断材料にしないでください。

「一部のWebサイトだけPROXY、その他はDIRECT」にしたい場合は、指定ドメインの条件を前に置き、最後のルールにFINAL,DIRECTを使います。上のフォールバック例とは方針が逆なので、両方の末尾ルールを同時に使わないでください。詳しくはDOMAIN-SUFFIXとFINALを使ったルールの書き方をご覧ください。Configを保存したら、動作中の旧版も残してください。誤った対象に一致した場合は、まず旧版に戻してから条件を一つずつ絞り込みます。

05 / VERIFICATION

接続と確認：システム状態から実際のリクエストまで

サーバー情報とルーティング方式を確認してから初回接続を始めます。Homeで識別しやすいサーバーを一つ選び、Global Routingとテスト対象が合っていることを確認してから接続スイッチをオンにしてください。初回はシステムの案内に従って許可します。スイッチを切り替えた直後に失敗と判断せず、接続の確立と最初のリクエストを待ちながら、アプリに明確なエラーが表示されるか確認してください。何度もスイッチを切り替えて再接続を繰り返さないでください。

確認を3段階に分ける

第1段階は、システムがVPN構成を正常に起動できたか。第2段階は、アプリが選択したサーバーと有効な通信を確立できたか。第3段階は、Webサイトへのリクエストが期待どおりに完了したかです。前の段階が成功しても、次の段階が成功するとは限りません。VPN状態が表示されていてもページが開かない場合は、認証、DNS、TLS、リモート側の出口、ルールなどが原因の可能性があります。スイッチがすぐオフに戻る場合は、システム権限、Configの読み込み、アプリに表示されたエラーを確認してください。

テストでは、まず何度もアクセスできる使い慣れた一般的なWebページを選び、次に現在のルールでPROXYを通るはずの接続先を試してください。Configを使う場合は、DIRECTを通るはずの接続先も確認し、すべてのリクエストが同じポリシーで処理されていないかを調べます。以前開いたページがキャッシュから表示されることがあります。ページを更新して新しいリクエストを確認してください。キャッシュされたタイトルや画像が表示されただけでは、現在のネットワークが接続できている証拠になりません。

Connectivity Testで確認できること

Connectivity Testの結果は、実際のテスト方法によって異なります。応答を計測できた場合、そのテストリクエストがその時点で応答を得たことは示せますが、すべてのプロトコル機能、接続先サイト、長時間の転送が正常とは限りません。レイテンシが低くてもスループットが高いとは限りません。回線帯域、混雑、リモート側の負荷、アプリからの具体的な経路が利用状況に影響します。方法の異なるテスト結果をそのまま並べて順位付けしないでください。

自分が利用する既存サーバーから少数を選び、同じ方法で繰り返しテストしてから、実際に必要なWebサイトを開いて確認してください。あるサーバーでテストに失敗してもWebページが開く場合は、テスト対象や方法が制限されていないかを確認します。テストは成功してもページが開かない場合は、DNS、ルール、接続先サイトを確認してください。数値の見方についてはレイテンシテストとサーバー選択の解説をご覧ください。単一の数値だけで判断しないでください。

エラーが発生した階層から順に切り分ける

すべての接続先で失敗する場合は、まずアプリを切断し、基本ネットワークが使えることを確認してから、サーバーアドレス、ポート、認証情報を確認します。TLSエラーの場合は、検証を無効にするのではなく、システム時刻、証明書に対応する名前、SNIを確認してください。UDPを使うプロトコルでは、現在のネットワークでUDPが利用できるかも確認します。あるネットワークで失敗しても、すぐに接続情報の誤りと判断せず、同じパラメーターを保ったまま、UDPを利用できる別のネットワークで比較してください。

特定のWebサイトだけ異常な場合は、その接続先のルールとリクエスト結果を優先して確認してください。Config全体をすぐに入れ替えないでください。Webサイト側のエラー、アカウントのログイン制限、地域によるコンテンツの違いは、アプリの接続失敗とは限りません。「接続を確立できない」「リクエストがタイムアウトする」「Webサイトから拒否応答を受け取る」を分けて記録してください。それぞれ原因の調べ方が異なります。

ネットワーク切り替え後の再テスト

Wi-Fiからモバイルデータ通信に切り替えると、既存の接続を再確立する必要があり、通信中のリクエストが中断されることもあります。システムのネットワークが安定してから接続先を更新してください。それでも失敗する場合は、一度手動で切断して再接続し、もう一度確認します。切り替え直後の数秒間にサーバー、ルール、DNSを同時に変更しないでください。どの操作で復旧したのか分からず、安定して再現できなくなります。

有効な確認結果は、「特定のネットワークで、特定のサーバーとGlobal Routingを使い、接続先への新しいリクエストが想定したポリシーで処理され、応答が完了した」と説明できるものです。このように記録しておくと、「使える」という一言より役立ちます。調査しても原因を特定できない場合は、FAQで問題の種類を選んで確認してください。機密情報を隠したエラーメッセージ、ネットワークの種類、再現手順を用意し、Subscribe URLやサーバー認証情報全体を公開しないでください。

06 / DATA

Data：通信量とリクエスト記録から状況を把握

Dataは、アプリが処理したトラフィックや接続を確認するための機能であり、サービス提供元の利用明細の代わりにはなりません。Dataを開いたら、現在の画面がリアルタイム接続、リクエスト記録、集計データのどれを表示しているかを確認し、集計期間にも注意してください。アップロード、ダウンロード、接続数、1件のリクエストの継続時間は、それぞれ異なる指標です。単位と範囲を確認せずに、一定期間の累積値を現在の速度と誤解しないでください。

アプリの通信量とSubscribeの使用量は異なる場合がある

ローカルの統計値は、再接続、データの消去、アプリの再起動、計測開始時点の影響を受けます。サーバー側では独自の期間や計測方法で記録されます。プロトコルの追加通信、失敗時の再試行、同じサービスを使うほかの端末によって、両者の数値が一致しないこともあります。そのため、端末のダウンロード量だけからSubscribeの残り通信量を推定できません。残量はサービス提供元の記録で確認し、アプリ内の統計は主に端末での通信状況を把握するために使ってください。

アップロードとダウンロードは通常、端末を基準にします。端末から外へ送る通信がアップロード、端末が受信する通信がダウンロードです。Webページを開くとダウンロードだけでなく、DNS、TLSハンドシェイク、リクエストヘッダー、応答確認などの送信も発生します。動画再生ではキャッシュ用の先読みが行われる場合があります。画面を操作しなくなった後に少量の通信があっても、すぐに異常とは限りません。バックグラウンドアプリ、同期、継続中の接続がないか確認してください。

接続先、ポリシー、結果から状況を追う

ルールを調べるときは、まず記録から直前に送信した接続先を見つけ、確認可能なドメイン名またはアドレス、一致したルール、最終ポリシー、接続結果を確認してください。画面によって表示できる項目は異なります。実際に記録された内容を基準にします。接続先にIPが表示されても、ドメインが存在しないとは限りません。アプリがIPを直接使う、キャッシュを再利用する、アプリから確認できる段階でドメイン情報が残っていない、といった可能性があります。

1つのWebページでも複数の接続が発生します。最上段の1件だけでサイト全体のポリシーを判断しないでください。テスト前に関係のないアプリを終了し、開始時刻を記録してから、対象ページを一度だけ更新すると確認しやすくなります。記録を消去する必要がある場合は、先に重要な状況を保存してください。消去は混乱を減らすための操作であり、サーバーやDNSを自動的に修復するものではありません。記録を絞ったあと、読み込めないリソースがメインページと異なるドメインやポリシーを使っていないか確認します。

よくある状況の見方

同じドメインに複数のアドレスが表示されるのは、ロードバランシング、名前解決結果の違い、複数リソースへの接続などが原因です。すぐに各IPを固定するルールを追加しないでください。固定したアドレスはサービスの変更で使えなくなったり、同じアドレスを共有する別サイトに影響したりする場合があります。まず接続先を正確に表せるドメインルールを使ってください。IP-CIDRは対象範囲の用途を明確に理解している場合に限り、変更後は一致結果を再確認します。

接続が長時間続いて通信量が少ない場合は、イベント待ちの長時間接続かもしれません。通信量が急に増えた場合は、システム同期やアプリの先読みが原因のこともあります。接続時間や合計通信量だけで異常と判断せず、起動したアプリ、接続先、操作時刻と合わせて確認してください。特定のアプリを終了すると現象が消え、再度開くと再現するなら、ルールをむやみに削除するより原因の特定に近づけます。

タイムアウトの記録は、所定の待ち時間内にリクエストが完了しなかったことを示します。原因はローカルネットワーク、サーバー、接続先サイト、応答経路などさまざまです。認証エラー、名前解決失敗、タイムアウトも区別してください。前の章の段階的な確認方法を使って、まず基本ネットワークを検証し、パラメーターを変えずに別のサーバーやネットワークと比較します。Dataが示すのは現象の記録であり、どちらに原因があるかを自動的に判断するものではありません。

記録のプライバシーと共有範囲

リクエスト記録には、アクセスしたドメイン、LANアドレス、利用時刻、アプリの動作が含まれる場合があります。共有するときは問題に直接関係する部分だけを抜き出し、Subscribe URL、認証情報、個人的な接続先を隠してください。パスワードが表示されていなくても、アクセス記録全体に機密情報が含まれる可能性があります。相談のために履歴全体をそのままエクスポートしないでください。通常は接続先の種類、ポリシー、エラーメッセージ、再現手順があれば調査を始められます。

ログや詳細記録に必要な保存容量と処理リソースは、記録件数に応じて増加します。トラブルシューティングが終わったら、日常利用に適した記録レベルに戻し、現在の画面で利用できる方法で不要な履歴を消去してください。変更の効果を比較する場合は、消去前に両方のテスト条件を記録します。後から統計値が小さくなっただけでは、新しいConfigの方が効果的だとは証明できません。

この章の目的は、すべてのリクエストを手作業で確認することではありません。問題が起きたときに、再現可能な証拠を少数集められるようにすることです。「明確なリクエストを送る—対応する記録を見つける—ポリシーと結果を説明する」の流れが確認できれば、通常の利用に戻れます。PROXYを通るはずの接続先がDIRECTになった場合はGlobal Routingの章へ、ポリシーが正しいのに接続できない場合は接続確認の章へ戻ってください。

07 / SETTINGS

Settings：問題に合わせて調整する

Settingsの各項目は影響範囲が異なります。アプリの表示設定、ネットワーク動作を変える項目、Configファイルにも記述できる項目があります。変更前に現在値を記録し、有効なConfigと、その設定がConfigによって上書きされていないかを確認してください。他人の設定画面をそのまま一般解として使わないでください。ネットワーク環境、サーバーパラメーター、ルールの対象が異なるため、同じスイッチの組み合わせでも逆の結果になることがあります。

DNS：どこで名前解決しているかを確認

DNSはドメイン名をアドレスに変換し、その結果が後続の接続やアドレスルールに影響します。問題を調べる際は、「ドメインから有効な結果を取得できない」状態と「アドレスは取得できたが接続できない」状態を区別してください。IPアドレスを直接使ったテストでは接続できる一方、ドメイン名で失敗する場合は、名前解決経路を確認する理由があります。同時にHTTPSの証明書名の要件も考慮してください。任意のIPへの接続結果を元のWebサイトへの接続結果と同一視しないでください。

ローカルでの名前解決と、プロキシ経由でDNSサービスに接続する場合では経路が異なります。どちらの動作になるかは、現在のConfigとSettingsを確認してください。DNSを変更した後はリクエストを再送し、キャッシュや既存接続に注意します。問題が解決することを期待して、一度に多数のDNSサーバーを追加しないでください。各アドレスの用途、ネットワークからの到達性、設定構文を確認し、理由を説明できる最小限の変更にとどめてください。

暗号化DNSが保護するのは該当する名前解決経路であり、すべてのアプリ通信がプロキシ経由になるわけでも、接続先へのTLS保護の代わりになるわけでもありません。LAN内の内部ドメインは、現在のネットワークが提供するDNSに依存することがあります。外部DNSに変更すると、内部リソースが使えなくなる場合があります。会社、学校、自宅のストレージでは内部ドメインと通常のWebサイトをそれぞれ確認し、公開Webサイトだけでテストを終えないでください。

On Demand：自動接続とルーティングを分けて考える

On Demandは、条件に応じて接続動作を開始する機能です。接続後にリクエストをどう処理するかはGlobal Routingが決めます。自動接続を設定しても振り分けルールは自動で作成されません。ルールを無効にしてもOn Demandが無効になるとは限りません。初回はまず手動接続を検証し、その後、特定のWi-Fi環境に応じた設定など、分かりやすい条件を一つ追加してください。複数の条件をまとめて設定してから、どれが動作したか推測するのは避けてください。

手動で切断しても自動接続する場合は、アプリを再インストールする前にOn Demandとシステムの自動接続状態を確認してください。複数のネットワーク条件を設定している場合は、それぞれの一致範囲と順序を確認します。Wi-Fi名は現在のネットワークと一致させ、モバイルデータ通信の条件は実際に切り替えて検証してください。詳しくはOn Demandによる条件付き接続の設定をご覧ください。

TLS、UDP、IPv6を調整するときの注意点

TLS関連の問題では、まずシステム時刻、SNI、サーバー証明書、トランスポートのパラメーターを確認してください。証明書検証を無効にするとセキュリティ上の境界が変わるため、通常の高速化や一般的な修復手段として使わないでください。サーバーのドメインが変更された場合、古いSNIや証明書名が適切でなくなることがあります。古い設定を残して検証を緩めるのではなく、元の情報を確認して更新してください。Config上のサーバーアドレスとTLS名は異なることがありますが、サーバー側の明確な指定に従う必要があります。

UDPが使えるかどうかは、プロトコルの機能、サーバー設定、現在のネットワークに左右されます。クライアントのスイッチをオンにするだけで、どのネットワークでもUDPが使えるようになるわけではありません。IPv6も単独のスイッチだけで決まるものではなく、端末、名前解決結果、ネットワークの出口、ルールが関係する場合があります。IPv6アドレスを返す接続先だけで問題が起きる場合は、記録を保存して条件を絞って比較してください。すべての接続問題をすぐにIPv6のせいにしないでください。

MTUなどのパラメーターはパケットサイズと通信経路に影響するため、初回設定時にむやみに変更しないでください。特定のネットワークで再現性のある通信問題があり、変更を裏付ける根拠がある場合に限って、段階的にテストします。一度に一つの値だけ変更し、変更前後のネットワークと接続先を記録してください。インターネット上の固定値を理由なく設定すると、一時的に症状が変わっても別の接続に影響する場合があります。

アプリの表示設定とネットワーク設定を分けて記録

表示、並べ替え、テストの設定は主に操作性に影響します。DNS、ルーティング、接続の設定はリクエストに直接影響します。この2種類の変更は分けて記録してください。リスト整理のためにRemarkを変更することと、サーバーアドレスを変更することは性質が異なります。トラブルシューティングでは、まず最近変更したネットワーク関連の項目を確認し、その後に表示設定を調べます。リスト順が変わっただけでサーバー情報がリセットされたと判断しないでください。

現在の画面に項目がない場合は、別のページで同じ名前のスイッチを無理に探さず、現在のConfigのパラメーターまたはサーバー詳細に属する設定かを確認してください。プラットフォームや画面によって項目の配置は異なります。このガイドでは、固定の位置を唯一の判断基準にしません。設定の役割、影響範囲、元に戻す方法を説明できることが、その設定を正しく調整できた基準です。他人と同じ状態にスイッチを変えるだけでは不十分です。

08 / MAINTENANCE

日常のメンテナンス：有効な設定と障害記録を保つ

安定して使えるようになった後に大切なのは、頻繁に設定を変えることではありません。どの情報が更新されるか、何をバックアップするか、問題が起きたときに既知の正常な状態へ戻る方法を把握しておくことです。サーバー一覧、Config、アプリの設定、システムのVPN権限はそれぞれ別の階層です。どの階層の変更も使用状況に影響する場合があります。簡単なメンテナンス習慣を作ると、サービスの期限、Subscribeの更新、ルール変更を混同せずに対処できます。

Subscribeの更新とConfigの更新を個別に確認

Subscribeを更新したら、内容を取得できたか、よく使うサーバーが削除または改名されていないかを確認してください。一覧の項目数だけで更新の良し悪しを判断しないでください。サービス提供元がサーバーの構成を変更する一方、ローカルに残った古い項目が表示され続けることもあります。更新後に接続できない場合は、現在選択中の項目が有効かを確認してから、認証パラメーターとサービスの状態を確認します。すぐにアプリ全体をリセットする必要はありません。

Configの更新ではルール、DNS、ポリシー名、その他の設定が変わることがあり、サーバー一覧だけの更新より広く影響します。更新前に現在動作しているConfigのコピーを保存し、更新後は固定した複数の接続先でPROXY、DIRECT、LANの動作を確認してください。ポリシー名が変更された場合は、以前の選択との対応関係も確認が必要です。自動更新は手動操作を減らせますが、重大なConfig変更を理解する代わりにはなりません。

用途と機密情報の範囲を確認してバックアップ

少なくとも、使用中のConfig、よく使うサーバーがどのSubscribeから取得されたか、ローカルで変更した内容を把握してください。現在の画面からエクスポートするときは、ファイルにサーバーパスワード、Subscribe URL、鍵、その他の認証情報が含まれていないか確認します。Configファイルがプレーンテキストでも、アカウントパスワードと同程度に機密性が高い場合があります。公開ディレクトリに置いたり、不特定の人に共有したりしないでください。

バックアップ名には「普段の振り分け用」「調整前のコピー」など用途を含め、区別しにくい数字だけの名前は避けてください。復元する場合は、コピーをインポートして、参照先のポリシーとサーバーが現在も存在するか確認してから、手動で接続します。古いバックアップのサーバーパラメーターがすでに無効になっている場合があります。「インポート成功」は「復元後も必ず使える」という意味ではありません。接続確認の章に沿って再テストしてください。

アプリの更新、機種変更、再インストール

iPhone / iPad版のアプリはApp Storeで更新します。再入手する場合は、購入時のアカウントで購入済み項目を確認してください。iPhone / iPad版はApp Storeで2.99米ドルの買い切り、Mac / Windows / Android / Linux版は無料です。この2種類の入手方法によって、接続サービスが別途必要であることは変わりません。機種変更の前に自分のConfigとSubscribe情報を保存し、アプリをインストールすればすべてのローカルデータが自動的に表示されると考えないでください。

PCやAndroidで更新する場合は、ダウンロードページから対応するインストーラーを再入手し、システムの警告にはインストール許可の手順に従って対応してください。MacではAppleシリコン版とIntel版を引き続き区別します。Linuxでは現在のディストリビューションに適したパッケージ形式を選びます。更新前にアプリを終了してローカルの変更を保存してください。更新後は以前の設定が残っているか確認してから必要な情報をインポートし、同じ内容を重複して作成しないようにします。

再現できる障害情報をまとめる

問題の記録は、発生時のネットワーク、選択中のサーバー、Global Routing、影響する接続先の種類、アプリが表示したエラーの5項目でまとめられます。Subscribe、Config、アプリを最近更新したか、アプリを切断すると基本ネットワークが使えるかも記録してください。こうした情報があれば、単に「急に使えなくなった」と伝えるより、権限、接続情報、ルーティング、リモート側のどこから確認するかを判断しやすくなります。

決めた順序で確認します。まず基本ネットワーク、次にサーバーの有効性、現在のConfigと一致したポリシー、最後に詳細設定を調べます。Proxyへの一時的な切り替えでルールの影響を切り分けられますが、確認後は普段のモードに戻してください。ネットワークを何度も切り替えてようやく接続できる場合は、成功したときだけでなく、毎回の条件を記録します。断続的な問題ほど比較用の記録が重要です。

• 再現する：同じ条件で繰り返し起きる場合は、変更と接続先を最小限に絞る。
• 特定のネットワークだけで起きる：パラメーターは変えず、利用可能な別のネットワークと比較する。
• 更新後だけ起きる：直前の正常なConfigに戻し、変更点を一つずつ比較する。
• 特定の接続先だけで起きる：接続先のリクエストとポリシーを確認し、すべての情報をリセットしない。

整理と切り戻しの完了基準

長期間使っていない個別サーバーや重複Configは整理できますが、まずポリシーから参照されていないかを確認してください。削除前に必要なバックアップを残し、削除後はよく使う接続先で再確認します。Subscribeから生成された項目が次回更新時に再び現れる場合は、何度も手動で削除するのではなく、取得元の管理方法を見直してください。サービスを使わなくなった場合は、認証情報のコピーや不要なQRコード画像も削除してください。

切り戻しが成功したかは、一覧が以前と同じ見た目に戻ったかではなく、明確なネットワーク条件で目的のリクエストを再度完了し、ルーティング方式を説明できるかで判断します。正常に戻ったら、一時的な詳細記録をオフにし、日常利用に必要なOn Demandの条件を戻して、最終的に有効なConfigを保存します。同様の問題が起きた場合は、この確認順序を再利用してください。短い手順はクイックスタート、具体的な質問はFAQを確認できます。毎回、すべての設定を削除するところから始めないでください。