Shadowrocket 完全ガイド:App Store での入手から日々のメンテナンスまで

Shadowrocket は App Store の有料アプリで、入手経路はほかにありません。この章では3つのことを整理します。ストアで自分が開いているのが正規版かどうかをどう確認するか、買い切りで一体何を買うのか、そしてどのデバイスにインストールできるのか。

Shadowrocket を App Store で検索すると、名前の似たアプリがいくつか結果に現れます。見分け方は名前ではなく、ストアページの3か所の情報です。開発者欄が Shadow Launch Technology Limited であること、アプリアイコンが白地に青紫グラデーションの輪郭で描かれたロケットの図形であること、ストアページの URL にアプリ ID 932747118 が含まれていること。3か所すべてが一致していれば、それが購入すべきアプリです。

アプリ ID を覚えておくべき理由

アプリ ID は App Store の各アプリに割り当てられた一意の番号です。当サイトのストアへのリンクはすべて https://apps.apple.com/jp/app/shadowrocket/id932747118 の1本に統一しています。アドレスバーに表示される id932747118 は、ストアページの情報にあるアプリ ID と同じものです。もしどこかのページが別の番号のリンクを示していたら、それは Shadowrocket を指していません。

買い切りで手に入るものは何か

Shadowrocket は買い切りの有料アプリです。米国ストアでの価格は約 2.99 ドルで、その他のストアでは現地通貨で表示されます。正確な金額は、ストアページを開いたときに表示される表記に従ってください。買い切りで購入できるのはクライアント本体、つまり iPhone と iPad 上で動作するこのアプリです。購入後に月額の購読料は発生せず、機能の解放のために追加で支払う必要もありません。

対応デバイスとシステム要件

Shadowrocket は iPhone と iPad が中心ですが、同じ App Store ストアページの互換性欄には Mac、Apple TV、Apple Vision も記載されています。あるデバイスにインストールできるかどうかは、そのデバイスでサインインしている Apple ID がこのアプリを購入済みかどうか、そしてストアページに現在表示されている互換性によって決まります。システムバージョンの要件は、必ず App Store ページの表記に従ってください。最低バージョンは OS の更新に合わせて変わるため、チュートリアルに書き固定めた数字はすぐに古くなります。

購入後:購入済みとアップデート

購入が完了すると、アプリはその Apple ID の購入済み項目に追加されます。機種変更や再インストールの際は、同じ Apple ID で App Store の購入済み項目から再ダウンロードすればよく、再度支払う必要はありません。ファミリー共有がこのアプリに適用されるかどうかも、ストアページの表記に従ってください。

アップデートは App Store が一括で配信します。アプリ内に独自の更新経路はなく、ファイルを手動で差し替える必要もありません。App Store の自動更新をオンにしておくか、ときどきアカウントページで手動更新を1回押せば十分です。当サイトはインストールパッケージを提供しませんし、提供できません。インストールパッケージを提供すると称する入手元は、いずれも正規版とは無関係です。

購入前に用意しておく2つのもの

購入ボタンを押す前に、2つ用意しておくことをおすすめします。1つはサーバー情報または購読リンク(プロバイダから取得するもの)、もう1つは、デバイスでサインインしている Apple ID が普段使っているものであることの確認です。前者は購入後すぐに使い始められるかどうかを、後者は将来機種変更したときに問題なく復元できるかどうかを左右します。インターフェースを先に眺めたいだけなら、サーバーが1つもない状態でもアプリは開けます。ただし接続スイッチはトンネルを確立できません。

Shadowrocket を初めて開くと、システムの許可ダイアログが続けて表示されます。それぞれが何のためのものか、許可すべきか、誤って押してしまった場合にどう挽回するかがこの章の内容です。あわせて、メイン画面のタブも一通り確認します。

初回起動で最初に現れるのは、通常 VPN 構成の許可ダイアログです。iOS は要求元の名前を明示し、VPN 構成の追加を許可するかどうかを尋ねます。許可を選ぶと、システムは Shadowrocket 用のローカルなトンネル構成を作成し、以降の接続スイッチはこの構成に基づいて動作します。

VPN 構成の権限が必要な理由

iPhone と iPad では、アプリが通信を自分の処理ロジックに通すために、システムが提供するネットワーク拡張フレームワークを利用する必要があります。Shadowrocket はサーバーパラメータとルールをシステムレベルの VPN 構成に変換し、通信はシステムからこのトンネルに入り、アプリがルールに従ってプロキシ経由か直接接続かを判断して、再びシステムに戻して送信します。システムの「設定」にこれに対応する VPN 構成項目が表示されるのはそのためです。これはシステム側に実際に存在する項目であり、アプリ内部の模擬スイッチではありません。

3つのダイアログはそれぞれ何に対応するか

• VPN 構成の許可(Add VPN Configurations):機能上必須です。拒否すると接続スイッチが効かなくなります。
• 通知の許可:接続状態の変化などの通知を表示するために使います。許可の有無はプロキシ機能に影響しません。
• ローカルネットワーク(Local Network):同じ LAN 内のほかのデバイスから本機のプロキシポートにアクセスさせたい場合にのみ必要です。その使い方が不要なら拒否してかまいません。

3つのダイアログのうち、必須なのは最初の1つだけです。「許可しない」を誤って押しても、アンインストールして入れ直す必要はありません。もう一度接続スイッチを操作すると、システムが改めて確認を表示します。それでもダイアログが出ない場合は、システムの「設定」の VPN の項目に関連する構成が存在するか確認してください。

メイン画面のタブ

Shadowrocket のメイン画面は下部のタブで構成され、以降の操作はすべてここから入ります。

• Home:サーバー一覧と接続スイッチ。上部に現在の Global Routing モード、中央にノード一覧、下部にメインスイッチが表示されます。
• Config:構成ファイルとルール。インポートした .conf ファイルやルールリストはここで確認・編集します。
• Data:通信量の統計。サーバー別とアプリ別の2組の数値があり、第7章で詳しく扱います。
• Settings:全体設定。On Demand、DNS、購読の自動更新などの項目がここにあり、第8章で詳しく扱います。

インターフェースの用語は英語表記のままにしています。Home、Config、Data、Settings、Add Server、Subscribe、Global Routing、On Demand。日本語の説明にこれらの語が出てきたら、画面上のその具体的なボタンやタブを指します。原文のまま残しているのは、1つずつ対応づけられるようにするためであり、意味の近い日本語に置き換えるためではありません。

推奨する初期設定の順序

最初の設定では、次の順序で進めると、スイッチを手当たり次第に押すより問題の切り分けがしやすくなります。

1. まず Settings で Global Routing のモードを確認します。既定の Config のままで問題ありません。
2. Home に戻り、Add Server または Subscribe でサーバー情報を入力します。
3. ノードの遅延テストを1回行い、パラメータが正しく入力されているか確認します。
4. 最後にメインスイッチをオンにし、Connectivity Test で1回検証します。

この順序の背景にある考え方は、スイッチは「トンネルを確立する」ことだけを担当し、トンネル内が通るかどうかはサーバーパラメータとルールが揃っているかで決まる、というものです。先に情報を入力してからスイッチを入れれば、失敗したときに問題をパラメータかネットワークに絞り込めます。権限・パラメータ・ルールの3つを同時に疑わずに済みます。なお、初回起動時に言語や外観を設定する必要はありません。インターフェースはシステムの言語とダークモードに従い、独立したテーマ設定はありません。

サーバー情報を Shadowrocket に入れる経路は2つあります。Add Server で1件ずつ手入力する方法と、Subscribe で購読をまとめてインポートする方法です。2つの経路は併用でき、この章ではそれぞれのフィールドの意味、更新方法、間違えやすい箇所を説明します。

Add Server:サーバーを1件手動で追加する

Home ページで Add Server をタップするとパラメータの入力フォームが開きます。最初の項目は Type で、これによって以降に入力するフィールドが決まります。

表はよくある組み合わせの一例にすぎません。フィールドは Type と選択した転送方式によって変わります。プロバイダから渡されたとおりに入力してください。余分に入力する、足りない、あるいは別の画面の名前から推測して入力するのは、接続失敗の最もよくある原因です。保存すると、ノードが Home の一覧に表示されます。

Type 以外にも見落としやすい点がいくつかあります。Remark は表示名にしか影響しないので、見分けやすい名前を付ければ十分です。TLS スイッチや SNI、Path、Host などのフィールドは、プロバイダが明示している場合にのみ入力が必要です。プロバイダが共有リンクや QR コードを提供している場合は、Scan QR Code で読み取ってインポートするほうが、手で写すより間違えにくくなります。

Subscribe:購読をインポートする

購読とは、プロバイダが複数のサーバーを1つのリンクにまとめ、クライアントが定期的に取得する仕組みです。入口は Home ページの Subscribe です。購読リンクを貼り付け、メモを書き、保存後に Update を押すと最初の取得が完了します。取得に成功すると、ノードはグループの形で一覧に表示されます。

購読リンクはプロバイダから取得するもので、https://example.com/sub?token=xxxx のような形式のアドレスです。通常は識別情報を含み、アカウントの資格情報と同じ意味を持つため、公開の場に貼ったり、関係のない人に転送したりしないでください。当サイトは購読リンクを一切提供しておらず、文中に登場するアドレスはすべて説明用の架空の値です。

購読と手動追加の違いは更新方法にあります。購読はまとめて更新でき、プロバイダがノードを変更しても Update をもう一度押すだけで済みます。手動で追加したノードは自動では変化しないため、プロバイダがアドレスを変えたら自分で修正する必要があります。2つの方式は併用でき、よく使うノードを手動で上に固定し、購読グループを下に置くのが一般的です。

購読を更新するタイミング

購読の更新には2つのタイミングがあります。手動更新と、Settings でオンにする自動更新です。手動更新の入口は購読グループ上にあり、グループの詳細を開くと Update が表示されます。自動更新は購読内容が頻繁に変わるユーザーに向いていますが、その代わりアプリを起動するたびに通信が1回増えます。

更新に失敗したときは、まず「取得できない」のか「取得できたが使えない」のかを切り分けます。前者は通常、リンクの失効や token の変更、現在のネットワークから購読ドメインに到達できないことが原因です。後者は購読内容自体に変化があったということで、プロバイダからの案内を確認する必要があります。詳しい切り分けの順序は第9章にあります。

ファイルから構成をインポートする

1件ずつ入力する以外に、Shadowrocket は構成ファイルのインポートにも対応しています。.conf ファイルを入手したら、システムの共有メニューから Shadowrocket を選ぶと Config ページにインポートできます。構成ファイルにはサーバー一覧、ルール、共通パラメータを同時に含められるため、完全な構成をすでに持っているユーザーに向いています。インポート後は Config ページ上部の選択状態を確認してください。複数の構成が存在する場合、有効なのは選択されている1つだけです。

ほかに Import from Cloud JSON という入口があり、クラウド上の JSON から構成を復元するために使います。読み込むのは自分で保存した構成内容であり、ノードの購読とは別のものです。

遅延テストとノードの選択

ノード一覧の各項目には遅延の数値が表示され、タップすると再測定できます。この数字は1回の疎通にかかった往復時間で、同じ時点のノードを横並びで比較するためにのみ使えます。実際の速度を表すものではありません。帯域も、長時間の安定性も測っていません。Connectivity Test はより完全なチェックを行い、結果は名前解決や接続などの段階ごとに分けて表示されます。

一覧は並べ替えと固定に対応しています。日常的には、安定した2〜3個のノードを最上部に置いておくと、毎回長い一覧を探し回らずに済みます。

Global Routing はトンネル内の通信が「既定でどこへ向かうか」を決める項目で、Shadowrocket の中で最も設定を誤りやすく、最初に理解しておく価値のあるものです。モードは Config、Proxy、Direct の3つだけです。

3つの関係はこう理解できます。メインスイッチは「トンネルを開くかどうか」、Global Routing は「トンネル内をどう流すか」を決めます。Direct に切り替えてもネットワークは切れず、プロキシサーバーを通る通信がなくなるだけです。Proxy に切り替えてもシステム自体には影響せず、Bypass リストにある LAN アドレスは引き続き直接接続されます。

Config モード:ルールがすべてを決める

Config は、日常使いで長期的に維持すべき唯一のモードです。このモードでは、Shadowrocket が Config ページのルールを上から下へ読み、最初にヒットしたルールがその接続を PROXY、DIRECT、REJECT のどれで流すかを決め、以降のルールは関与しません。ルールの書き方と順序は第5章で扱います。

Config モードに切り替える前に、Config ページに選択済みの構成が1つあることを確認してください。構成ファイルがない、または構成ファイルにルールがない場合、Config モードの挙動はフォールバックルールに完全に委ねられ、結果は期待と食い違いがちです。これも「プロキシをオンにしているのに、あるサイトが開けない」というよくある原因の1つです。

Proxy と Direct:2つの一時モード

Proxy モードは「今日は全部プロキシ経由にしたい」という場面に向いています。Bypass されていないすべての通信が、現在選択中のサーバーから出ていき、ルールは判断に関与しません。副作用も直接的で、本来は直接接続すべき LAN アクセスや、本来は通信量を節約できる近隣のリクエストまで遠回りし、速度と通信量の両方に影響します。

Direct モードは「構成を保ったままのオフ状態」と考えるとわかりやすいでしょう。トンネルは確立されたままですが、プロキシに入る通信はありません。プロキシを一時的に止めたいが、現在のノード選択は失いたくない場面に向いています。使い終わったら Config に戻すのを忘れないでください。戻さないと、次の接続も Direct のままになります。

On Demand との役割分担

On Demand(必要時接続)が決めるのは「いつ自動でつなぎ、いつ自動で切るか」で、Global Routing が決めるのは「つないだ後にどう流すか」です。両者は直交しています。On Demand でモバイル通信時に自動接続させつつ、Global Routing は Config モードのままルールで振り分ける、という設定が可能です。この2つを混ぜて調整し始めると、設定がどんどん乱れていくよくある入口になります。

現在のモードを確認する方法

Home ページの上部に現在の Global Routing モードが表示されます。メインスイッチをオンにしてステータスバーに VPN アイコンが出ても、それはトンネルが確立したことしか示しません。通信が必ずプロキシを通ったとは限らず、実際に通ったかどうかは Data ページの数値で確認します(第7章)。

実用的な自己チェックの習慣を1つ挙げます。Global Routing やルールを調整するたびに、ルールに明記したドメインを開き、Data ページに戻ってその通信がどの数値グループに計上されたかを見てから、さらに変更するかどうかを決めます。

よくある3つの設定ミス

• Direct を「アプリをオフにする」感覚で常時オンにしたままにし、購読の更新やノードの速度測定が異常になる。
• Proxy を「より徹底した振り分け」だと思い込む。実際にはすべてのルールを迂回している。
• Config モードでフォールバックルールがなく、どのルールにもヒットしない通信の行き先が予測できなくなる。

ルールは Config ページの構成ファイルに書き、形式は「種類,パラメータ,ポリシー」の3段で統一されています。この章では各タイプが何にマッチするか、順序がなぜ重要なのかを説明し、そのまま使える最小の断片も示します。

1つのルールは何で構成されるか

ルールの基本構造は 種類,パラメータ,ポリシー です。種類は何と比較するかを決め、パラメータは比較の根拠、ポリシーはヒット後の流し方を決めます。ポリシーは3つあり、PROXY はプロキシ経由、DIRECT は直接接続、REJECT は遮断です。たとえば DOMAIN-SUFFIX,example.com,PROXY は、example.com とそのサブドメインへのリクエストをすべてプロキシ経由にする、という意味です。

よく使うルールタイプ一覧

DOMAIN と DOMAIN-SUFFIX の違いは個別に覚えておく価値があります。前者は書いたその1つのドメインだけにマッチし、後者はそのすべてのサブドメインも一緒にマッチします。example.com と www.example.com は、DOMAIN-SUFFIX なら1行でカバーできますが、DOMAIN では2行書く必要があります。

順序:上から下へ、先にヒットしたものが有効

ルール一覧には順序があります。Shadowrocket は1行目から順に照合し、最初にヒットしたルールがその接続の行き先を決め、以降のルールは関与しません。ここから2つの実践原則が導かれます。1つは、具体的なルールを広いルールより前に置くこと。たとえば DOMAIN は DOMAIN-KEYWORD より前に置きます。もう1つは、フォールバックの FINAL は必ず最終行に置くことです。そうしないと、後ろのルールをすべて遮ってしまいます。

GEOIP ルールは対象の IP を取得してからでないと所属を判定できないため、通常はドメイン系のルールより後ろに置きます。ドメインで判定できるものは先に判定し、できないものを IP 層に任せる、という考え方です。これはルール順序について最もよく聞かれる点です。

そのまま使える最小の断片

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,203.0.113.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
USER-AGENT,Example*,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

この構成が表すポリシーは次のとおりです。example.com とそのサブドメインはプロキシ経由。ただし api.example.com と example というキーワードを含むリクエストは例外として直接接続。2つのサンプルネットワーク範囲は直接接続。中国本土の IP は直接接続。それ以外はすべてプロキシ経由。ドメインとネットワーク範囲を自分の対象に置き換えれば、形式は変えずに使えます。

少数の対象だけをプロキシ経由にし、それ以外をすべて直接接続にしたい場合は、フォールバックを FINAL,DIRECT に変え、その前にプロキシ経由にしたいドメインを並べます。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
GEOIP,CN,DIRECT
FINAL,DIRECT

2つの考え方に優劣はなく、使い方次第です。前者は「既定でプロキシ経由、例外は直接接続」、後者は「既定で直接接続、例外はプロキシ経由」です。どちらか一方に決めれば、ルール一覧はずっと見通しがよくなります。

REJECT と遮断の境界

REJECT ポリシーはヒットした接続を遮断するもので、特定のドメインをブロックするのによく使われます。その境界は明確にしておきましょう。効果があるのはマッチできるドメインや IP に対してだけです。HTTPS 接続が遮断された場合、現れ方は接続失敗や読み込みタイムアウトであり、「内容がフィルタリングされた」わけではありません。アプリが独自に発行するリクエストや、ドメインフロンティング、独自の名前解決を使うリクエストは、ルールを完全に迂回する可能性があります。したがって REJECT を汎用的なブロック手段と考えないでください。あくまでルール層のスイッチの1つです。詳しい説明は当サイトのブログ「Shadowrocket の REJECT ポリシー:遮断の仕組みと境界」にあります。

ルールを変更した後

ルールの変更を保存した後は、構成を再読み込みさせる必要があります。Global Routing を一度切り替えるか、メインスイッチをオフにしてからもう一度オンにすれば済みます。変更量が多いときは、まず新しいルールを1つだけ小さい範囲で検証し、ヒットを確認してからまとめて追加することをおすすめします。何十行も一度に書いてから遡って調べるのは、はるかに手間がかかります。

情報を入力し、ルールが揃ったら、最後は接続と検証です。この章では、スイッチと状態の見方、Connectivity Test が何を確認するのか、つながらないときにどの順序で切り分けるかを説明します。

接続をオンにするときの状態表示

Home ページ下部のスイッチがメインスイッチです。オンにすると、システムのステータスバーに VPN の表示が出て、アプリ内のスイッチもオン状態になります。この2つの表示はトンネルが確立したことしか示しません。通信がプロキシを通ったかどうかは、Data ページの数値と現在のモードで確認します。

ノードの選択は一覧で行います。ノードの行、またはその前の丸印をタップすると、現在のノードに明確な印が付きます。ノードの切り替えにスイッチの入れ直しは不要で、トンネルは新しいノードで再構築されます。

Connectivity Test が確認する内容

Connectivity Test はいくつかの項目を順に確認します。ドメインの名前解決が正常か、選択したサーバーに接続できるか、そしてサーバー経由で外部アドレスにアクセスできるかです。結果には各段階の状態が個別に表示され、失敗した場合は最初に問題が起きた段階で止まります。

結果は上から下へ読むのがコツです。名前解決に失敗していれば DNS の段階に問題があります。接続に失敗していれば、サーバーのアドレス、ポート、プロトコルのパラメータが一致していません。名前解決と接続は成功しているのに外部アクセスに失敗する場合は、サーバー側の状態である可能性が高く、プロバイダから提供された情報を基準にしてください。

振り分けが実際に効いているか確認する方法

振り分けの確認に追加のツールは不要で、Data ページだけで完結します。

1. PROXY と明記したドメインを開き、Data ページに戻って、その通信が現在のサーバーの数値に計上されているかを見ます。
2. DIRECT と明記したドメインを開き、サーバーの数値が増えていないことを確認します。
3. 手順2の数値も増えている場合は、Config ページに戻ってルールの順序を確認し、より前にあるルールが先にヒットしていないか確かめます。

この3ステップの自己チェックで、「ルールは書いてあるのに効かない」というほとんどのケースをカバーできます。

接続に失敗したときの切り分け順序

つながらないときは、次の順序で1つずつ除外していくほうが、アプリを何度も入れ直すよりはるかに効率的です。

1. 権限:VPN 構成の許可が拒否されていないか、システムの「設定」の VPN の項目に対応する構成が存在するかを確認します。
2. パラメータ:Address、Port、Password または UUID がプロバイダから渡された情報と一致するか、1文字ずつ照合します。大文字小文字の違いや余分な空白にも注意してください。
3. プロトコルの詳細:Type が正しく選ばれているか、TLS、SNI、Path、Host などのフィールドがプロバイダの説明どおりに入力されているかを確認します。
4. 時刻:デバイスの時刻が大きくずれていると TLS ハンドシェイクに影響します。時刻の設定を自動にしてください。
5. モード:Global Routing が Direct のままになっていないか確認します。
6. 購読の状態:ノードが購読由来の場合は、先に購読を1回更新してから判断します。
7. ネットワーク環境:別のネットワークに切り替えて(たとえば Wi-Fi からモバイル通信へ)試し、現在のネットワークによる VPN の制限を除外します。

7つの手順のうち、最初の4つでほとんどの失敗例をカバーできます。すべて試しても通らない場合は、Connectivity Test の結果をプロバイダと突き合わせてください。問題はサーバー側かアカウントの状態にある可能性が高く、クライアント側で対処できる範囲を超えています。

断続的な切断

つながるものの時々切れる場合、原因はネットワークの切り替え、ノードの負荷、ルールの衝突などが一般的です。まず切れるタイミングを観察します。Wi-Fi とモバイル通信を切り替えたときに切れるなら、ネットワーク切り替えによるトンネル再構築が原因である可能性が高いです。決まった時間帯に切れるなら、ノード側の問題かもしれません。特定のアプリを使うときだけ切れるなら、そのアプリのドメインが REJECT に入っていないか、あるいは誤って直接接続に振られていないかをルールの中で探します。

Data ページはトンネルを通った通信を2つの軸で集計します。サーバー別とアプリ別です。この章では、2組の数値がそれぞれ何を数えているのか、なぜシステムの統計と一致しないのか、そして異常な通信を特定するときの手順を説明します。

2組の数値はそれぞれ何か

サーバー別の組は、各ノードが担った上りと下りの通信量を集計します。用途は「通信がどの回線から出ているか」の判断で、複数のノードを比較して選ぶときに最も分かりやすい指標です。アプリ別の組は、各アプリが発生させた通信量を集計します。用途は「誰が通信を使っているか」の判断です。

2組の数値の単位は B、KB、MB、GB で、1024 進法で換算されます。画面では通常、上りと下りが別の列で表示されます。注意したいのは、ここで集計されるのは Shadowrocket のトンネルを通った通信であり、デバイスのネットワークインターフェース全体の送受信ではないという点です。

システムの統計と一致しない理由

システムの「設定」にあるモバイル通信の統計と Data ページの数値は、しばしば一致しません。理由は3つあります。

• 集計範囲が違う:システムの統計はネットワークインターフェース層の送受信で、直接接続の通信やシステム自身のリクエストも含みます。Data ページはトンネルに入った分だけを数えます。
• 集計期間が違う:システムの統計は請求サイクルや手動リセットの区間で累積されます。Data ページのカウントは、前回リセットした時点かインストール時点から始まります。
• 処理方法が違う:一部のプロトコルは通信を追加でカプセル化するため、トンネル内のカウントと実際のインターフェースのカウントには正常な範囲の差が生じます。

この3つが重なるため、2組の数字が一致しないのはむしろ普通で、「統計が壊れた」と判断する必要はありません。プランの使用量を判断するときは、プロバイダの管理画面の数値を基準にしてください。Data ページは相対的な比較に向いています。

異常な通信を特定する手順

通信量の消費が異常だと気づいたら、「総量 → サーバー → アプリ → ルール」の順に見ていきます。

1. まず総量の増加速度を見て、異常が継続的に起きているのか、特定の期間に集中しているのかを確認します。
2. 次にサーバー別の数値を見て、最も多くの通信を担っているノードを探します。
3. 続いてアプリ別の数値を見て、具体的なアプリを特定します。
4. 最後に Config ページに戻り、そのアプリのドメインが本来は DIRECT であるべきなのに、前にあるルールによってプロキシへ送られていないかを確認します。

手順4は最も飛ばされやすく、最も成果が出やすい手順です。「なぜか通信量が増えた」というケースの多くは、ある広いルールが本来は直接接続すべきリクエストをプロキシへ引き込んでいることが根本原因です。関連する数値の詳しい解説は当サイトのブログ「Shadowrocket の Data ページの通信量統計の見方」にあります。

リセットと記録

Data ページにはリセットの入口があり、リセットするとカウントはゼロから始まります。ルールを調整する前後でそれぞれ1回リセットし、2つの区間の数値を比べるほうが、累積の数字を眺めるより変更が効いたかどうかを判断しやすくなります。

最後に1点。Data ページの通信量統計と、あなたの回線プランの使用量は別物です。プランの残量、請求サイクル、超過時の扱いはプロバイダが決めるもので、プロバイダの管理画面が基準です。クライアント側では、自分を通った分しか見えません。

Settings ページには、ノードによって変わらない全体設定がまとまっています。この章では、日常で実際に触ることになる項目を選び、それぞれが何を解決するのか、どんなときに変更が必要なのかを説明します。

On Demand:必要時接続

On Demand は、アプリがどのネットワーク条件で自動接続・自動切断するかを決めます。トリガー条件は3種類あります。

• Wi-Fi:現在接続している Wi-Fi の名前でマッチし、特定のネットワークでは自動接続、別のネットワークでは自動切断、といった指定ができます。
• モバイル通信:モバイルデータ通信時に自動接続します。「外出したら自動でオン」という使い方によく使われます。
• ドメイン:特定のドメインへのアクセス時に接続をトリガーします。ネットワークではなく目的の対象で判断したい場面に向いています。

3種類の条件は組み合わせられ、組み合わせた場合は「または」の関係になります。どれか1つを満たせばトリガーされます。よくある設定ミスは、互いに矛盾する2つの条件を書いてしまうことです。たとえば Wi-Fi では切断を要求し、同時にドメインで接続を要求すると、接続状態が繰り返し切り替わるという挙動になります。設定後は、実際にネットワークを切り替える場面で1回検証することをおすすめします。より細かいパラメータの説明は当サイトのブログ「Shadowrocket の On Demand:Wi-Fi・モバイル通信・ドメインのトリガー設定」にあります。

DNS

DNS 設定は、ドメインの名前解決がどの経路を通るかを決めます。既定のシステムに従う設定でほとんどの場面は足ります。解決サーバーを指定したい場合は、この項目にアドレスを入力します。DNS を変更するとドメイン系ルールの判定結果に直接影響するため、変更後は第6章の3ステップの自己チェックで1回確認してください。

注意しておきたいのは、DNS と振り分けは2層のロジックだという点です。まずドメインに対応するアドレスを解決し、そのうえでルールがその接続の流し方を決めます。解決の段階で問題が起きていれば、ルールがどれだけ正しくても効きません。

Bypass と LAN

Bypass リストにあるアドレスは決してトンネルに入りません。よくある例は LAN のネットワーク範囲と本機のアドレスです。既定値は一般的なプライベートネットワーク範囲をすでにカバーしているため、アクセスしたい LAN サービスが明確にない限り変更は不要です。パブリックアドレスを誤って Bypass に追加すると、本来プロキシを通すべき通信がそのまま外に出てしまいます。

購読の自動更新

この項目は購読の更新タイミングを制御します。オンにすると自動更新、周期に応じた自動更新が行われます。購読内容が頻繁に変わるユーザーはオンをおすすめします。購読が安定しているユーザーはオフにして、起動のたびの通信を減らしてもかまいません。スイッチの状態にかかわらず、手動の Update はいつでも使えます。

プロキシポートと LAN 共有

Shadowrocket は本機でプロキシポートを待ち受け、同じ LAN 内のほかのデバイスに使わせることができます。オンにするにはローカルネットワークの権限を許可する必要があります(第2章で触れた3つ目のダイアログです)。用途が明確な機能なので、本当にほかのデバイスへプロキシを提供したいときだけオンにし、使い終わったらオフにしてください。

ログと診断

ログのスイッチは接続の過程を記録するためのものです。難解な問題を調べるときにオンにして、1回再現させ、またオフにして、ログの内容をプロバイダと突き合わせます。日常はオフのままで十分です。つけっぱなしにすると容量を消費するだけです。

iCloud 同期とバックアップ

構成は iCloud を通じてデバイス間で同期できます。オンにしておけば、機種変更のときにルールを整理し直す必要がありません。オフでも使用には影響せず、手動でエクスポートとインポートを行えば済みます。どちらでもかまいませんが、大切なのは一方に決めて一貫させることです。2台のデバイスでルールの版が互いを上書きしてしまうのを避けられます。

触らなくてよい項目

Settings には、外観、通知、実験的な機能に関するスイッチも多数あります。そのほとんどは妥当な既定値を持っており、明確な必要がないときは既定のままにしておくのが、構成を予測可能に保つ最も簡単な方法です。1項目変える前に、まず「それが何を解決するのか」を考えてみてください。答えが出ない変更は、たいてい数週間後に新たな混乱になります。

最後の章では日々のメンテナンスを扱います。購読の更新に失敗したときの調べ方、ノードが使えなくなったときの対処、機種変更時の移行、そして実はやらなくてよい操作についてです。

購読の更新に失敗したときの切り分け順序

1. リンク自体:購読リンクに欠けた文字がなく、期限切れでもなく、プロバイダが現在提供しているものと一致するかを確認します。
2. ネットワーク到達性:購読ドメイン自体がプロキシ経由でないとアクセスできない場合があります。先に使えるノードに接続してから更新してください。
3. 返却形式:更新は成功したのにノード一覧が空の場合、返ってきた内容がクライアントの解釈できる形式ではありません。プロバイダに確認してください。
4. アカウントの状態:プロバイダの管理画面の状態を基準にしてください。クライアントからはアカウント側の情報は見えません。

4つの手順を試しても失敗する場合は、更新時に表示されたメッセージをそのままプロバイダに送るほうが、「使えない」と説明するよりはるかに有効です。関連するよくある原因は当サイトのブログ「Shadowrocket の購読更新:手動更新・起動時の自動更新と失敗の原因」でより詳しく展開しています。

ノードの失効と切り替え

1つのノードだけつながらない場合は、まず遅延を1回測り、別のノードに切り替えて比べます。同じ購読内の複数のノードが同時に使えなくなった場合は、ノードのパラメータを1つずつ調べるより、購読の更新やアカウント状態の変化を先に疑ってください。複数のノードの間を行き来しても安定性は改善しません。使えるノードを2〜3個に固定し、残りは予備として残しておくほうが手間がかかりません。

ルールと構成のメンテナンス

ルールは構成の中で最も冗長な部分が溜まりやすい箇所です。定期的に整理することをおすすめします。もうアクセスしないドメインのルールを削除し、重複した項目をまとめ、フォールバックルールが最終行にあることを確認します。変更の前に現在の構成をエクスポートして控えを1つ残してください。構成ファイル自体はとても小さいので、バックアップの手間はほとんどありません。

ルールがリモートリストを参照している場合は、そのリスト自体の更新頻度に注意してください。リモートの内容にアクセスできなくなっても、ローカルにあるルールはそのまま動作し、接続が中断されることはありません。ルールの書き方の体系的な解説は当サイトのブログ「Shadowrocket のルールの書き方:DOMAIN、GEOIP、IP-CIDR、FINAL はそれぞれ何にマッチするか」にあります。

機種変更と再インストール

新しいデバイスに移るときは、まず新しいデバイスで同じ Apple ID を使い、App Store の購入済み項目から Shadowrocket を再ダウンロードします。次に iCloud 同期か、以前にバックアップした構成のインポートを行い、最後に購読リンクを入れ直します(購読リンクはアカウントの資格情報にあたるため、同期の範囲は自分のバックアップ方法に従います)。

アプリを再インストールする前に、構成をエクスポート済みか確認してください。アンインストールするとローカルの構成も一緒に消えるため、この手順に後戻りはできません。

アプリの更新と OS のアップグレード

アプリの更新は App Store 経由で、普通のアプリと変わりません。OS のメジャーアップグレード後に接続の挙動が変わった場合は、まず VPN 構成の許可がまだ有効かを確認し、そのうえで第6章の7つの手順で1回切り分けてください。アップグレード後に権限がリセットされるのはよくある現象で、アプリに問題が起きたわけではありません。

よくある3つの誤解

• クライアントを回線だと思う:アプリを買い切っても通信量が手に入るわけではありません。ノードと購読は常にプロバイダから取得するものです。
• 「接続成功」を「回線が使える」と思う:ステータスバーのアイコンはトンネルが確立したことしか示しません。実際に通るかどうかは検証結果で確認します。
• ルールを万能スイッチだと思う:ルールが決められるのは通信の流し方だけです。サーバー側の状態を変えることはできず、プロバイダが提供するサービスの代わりにもなりません。

次に読むもの

このページは全体の流れを扱っています。まずは素早く通したいだけなら、使い方チュートリアルの5ステップの本線に戻ってください。具体的な問題に遭遇したら、よくある質問ページが「正規版の確認と購入 / インストールと初回起動 / 購読とノードのインポート / ルールと振り分け・トラブルシューティング」の4分類でQ&Aを整理しています。ある分野を深く知りたいときは、ブログで特集記事を探してください。