Shadowrocket
使い方完全ガイド

入手とインストール

まず使用するプラットフォームを確認し、入手先を選びます。iPhone / iPad版はApp Storeから入手します。Mac、Windows、Android、Linux版は当サイトのダウンロードページからインストーラーを選択してください。ファイルは当サイトの /dl/shadowrocket/ から提供します。スマートフォンの購入履歴をパソコン版のインストール手順と混同しないでください。また、ダウンロードしただけでは設定は完了しません。インストールで用意できるのはクライアントのみです。接続には、ご自身が保有するサーバー情報またはサブスクリプションURLが必要です。

iPhone / iPadのApp Store掲載情報を確認する

ダウンロードページのApp Storeリンクから製品ページを開き、アプリ名がShadowrocket、デベロッパ名がShadow Launch Technology Limited、アプリIDが932747118であることを確認してください。アイコンが当サイトのヘッダーにある公式アイコンと一致することも確認します。これらの情報を照合すれば、Shadowrocketで検索するだけの場合より確実です。名前が似ていても、同じアプリとは限りません。iPhone / iPadのシステム要件はApp Storeの製品ページに記載された内容を確認し、インストール前にお使いの端末が要件を満たしているか確認してください。

iPhone / iPad版はApp Storeで$2.99の買い切り、Mac / Windows / Android / Linux版は無料です。App Storeではアカウントのストア地域に応じた通貨で表示されるため、購入前に製品ページを確認してください。別のiPhoneやiPadで使う場合は、購入時と同じアカウントでサインインしていることを確認し、購入済み項目から探してください。検索しても見つからない場合は、アカウントの地域とアプリの提供状況を確認しましょう。ストアの問題を解決するために、クライアントの設定を何度も変更する必要はありません。

パソコン・Android用インストーラーを選ぶ

MacにはAppleシリコン版とIntel版があり、どちらもダウンロードページから入手できます。「このMacについて」を開き、Appleシリコンの名称が表示される場合はAppleシリコン版、Intelプロセッサと表示される場合はIntel版を選択してください。ダウンロードしたディスクイメージを開き、アプリをApplicationsに移動してから、そのフォルダ内のアプリを起動します。ディスクイメージから直接起動し続けると、アプリの更新やダウンロードファイルの整理、システム権限の確認時に保存場所を間違えやすくなります。

Windowsではダウンロードページにあるインストーラーを選び、起動中の旧バージョンを終了してからインストールします。Androidでは対応するarm64インストーラーを選択してください。端末に互換性がないと表示された場合は、何度もインストールを試すのではなく、端末のアーキテクチャとシステム要件を確認します。Linuxではディストリビューションに合わせてdebまたはrpmを選択してください。AppImageは単体ファイルとして実行する場合に適しています。入手先は全プラットフォーム版のダウンロードにまとめています。このマニュアルでは、変更される可能性のあるインストーラー名を個別に記載していません。

初回起動時のシステムによるブロック

デスクトップ版とAndroid版のインストーラーにはコード署名がないため、初回起動時にシステムによってブロックされる場合があります。警告に対処する前に、ファイルを当サイトのダウンロードページから入手したこと、端末に合ったファイル形式であること、システムに表示されたアプリ名を確認してください。組織で管理されているパソコンでは、ユーザー自身で許可できない場合があります。その際は端末の管理者に相談してください。アプリを起動するために端末全体のセキュリティ保護を無効にしないでください。また、入手先が不明なファイルに以下の操作を行わないでください。

Macでアプリが「破損している」と表示された場合は、まず今回ダウンロードしたファイルを削除し、当サイトから再取得して、ダウンロードの中断やパッケージの選択ミスを除外してください。アプリがApplicationsに配置され、入手元に問題がなく、隔離属性が原因と確認できた場合に限り、ターミナルで次のコマンドを実行します。このコマンドはアプリのフォルダに含まれる拡張属性を再帰的に削除するもので、実際に破損したファイルを修復するものではありません。コマンドの対象範囲を広げないでください。操作後にアプリを再起動しても解決しない場合は、警告の全文を残して引き続き原因を確認してください。

xattr -cr /Applications/Shadowrocket.app

LinuxでAppImageを使う場合は、ファイルマネージャーの権限設定で実行を許可すると、ファイル名の入力ミスを防げます。許可しても起動しない場合は、ディストリビューションに必要な実行環境とターミナルのエラーを確認してください。実行環境の不足をサブスクリプションの問題と混同しないようにしましょう。チップの選び方やシステム警告について詳しくは、Mac・Windowsのインストール方法とLinuxのインストール形式をご覧ください。

初回起動と権限

初回起動時は、まず画面を確認してから接続に必要な権限を設定します。iPhone / iPadでは主にHome、Config、Data、Settingsを使います。Homeではサーバーの管理と接続、Configではルール設定、Dataでは通信関連の記録確認、Settingsではクライアントの動作設定を行います。画面の言語やシステムのレイアウトによって項目の位置が異なる場合があります。ボタンの色だけで判断せず、設定名と現在の画面を確認して操作してください。

アプリの設定とシステムのVPN設定を区別する

アプリ内のサーバー、サブスクリプション、ルールファイルはアプリの設定です。システムに表示される「VPN構成を追加」は、端末のネットワーク権限に関する設定です。両者は別のものです。サーバーをインポートしてもシステムの許可が完了したことにはならず、システムの許可が済んでも利用可能なサーバーがあるとは限りません。初回接続時にShadowrocketがシステムのVPN構成を追加するため、許可すると、処理対象の端末通信をクライアントに渡せるようになります。この表示が出たことだけでは、サーバーに接続できたとは判断できません。

許可する前に、Shadowrocketから接続を開始したことを確認し、システムの指示に従って端末のパスコードまたは生体認証で承認してください。ここで必要なのは端末のロック解除認証であり、サブスクリプションのパスワードやサーバーの認証情報ではありません。いったんキャンセルした場合は、Homeに戻り、サーバー情報がそろっていることを確認してから接続スイッチを再度オンにしてください。許可を何度もキャンセルしたり、ルールを繰り返し切り替えたりしても、未許可の問題は解決しません。

許可後は、システム設定のVPN関連画面で構成を確認できます。項目の階層はシステムのバージョンによって異なるため、システム設定の検索でVPNを探してください。システムのVPN構成を削除しても、通常はアプリ内のサーバーは削除されませんが、次回接続時に再度許可が必要です。用途が分からないまま、組織や仕事用アプリのネットワーク構成を削除しないでください。管理対象の端末では、構成の追加や削除が管理ポリシーによって制限され、ユーザー自身で復元できない場合があります。

操作に応じて必要な権限を許可する

QRコードをスキャンすると、システムからカメラの使用許可を求められる場合があります。Scan QR Codeを使う場合に限り許可してください。拒否しても、既存のテキストリンクや手入力でインポートできます。カメラの許可を再度有効にする場合は、アプリを再インストールするのではなく、システム設定でShadowrocketの権限ページを開いてください。スキャン前にQRコードの入手元も確認しましょう。読み取れたことは形式を認識できたという意味であり、記載された情報がアカウントに適している、または有効であることを示すものではありません。

クリップボードから内容をインポートする際、貼り付けを許可するか確認される場合があります。まず、コピーしたものが自分の共有リンクまたはサブスクリプションURLであることを確かめてから、操作を許可してください。クリップボードには以前コピーした内容が残っている場合があるため、インポート後に種類、メモ、ホスト名を確認します。ローカルネットワーク上の端末にアクセスする場合は、システムのローカルネットワーク権限にも注意してください。この権限はVPN接続に必要なシステム許可とは別のもので、同じスイッチとして扱わないでください。

初回利用時に、警告を消すためだけにすべての権限を有効にする必要はありません。まず必要な操作を行い、表示された警告を読み、その操作に必要な権限だけを許可してから結果を確認しましょう。使う予定のない機能は、設定を変更せずに構いません。通知、カメラ、ネットワーク構成の各権限は用途が異なります。権限が拒否された場合は、影響を受ける具体的な機能を確認し、クライアント全体が動作しないと判断しないでください。

以前の接続や管理ポリシーの影響を確認する

端末にほかのVPN接続やネットワーク拡張機能がある場合は、今回のテストと競合する接続を停止してからShadowrocketを起動してください。複数のアプリがシステムのネットワーク経路を同時に使うと、スイッチを入れてもすぐ切れる、状態が変わり続ける、リクエストが以前の接続を通る、といった症状が出ることがあります。原因を調べる際は、必要な接続だけを一つ残し、停止前の状態を記録してください。テスト後は必要に応じて元に戻します。すべてのネットワーク構成を頻繁に削除して、個別の競合を特定しようとしないでください。

公衆Wi-Fiでは、ブラウザで認証ページを開いてログインする必要がある場合があります。認証ページでの手続きが済んでいないと、クライアントの接続テストやサブスクリプションの更新に失敗することがあります。まず接続を一時停止し、通常のネットワーク接続で認証ページを開いてログインしてから、クライアントに戻ってください。モバイル通信とWi-Fiのどちらでも、まず基本的なインターネット接続が必要です。ネットワーク自体につながっていなければ、サーバー情報が正しくてもリモート接続はできません。システムのVPNアイコンは、ネットワーク接続そのものの代わりにはなりません。

権限を設定した後は、まずOn Demandをオフにしたまま、手動接続を一度試してください。手動操作による状態変化と自動接続の動作を切り分けやすくなります。システム構成を誤って削除した、許可を繰り返し求められる、設定に該当項目が見つからない場合は、VPN構成の追加を求められる場合の説明をご覧ください。「接続できない」とだけ記すより、警告の全文を残すほうが次の確認事項を特定しやすくなります。

サーバーとサブスクリプションの追加

まず手元にある情報の種類を確認します。個別の共有リンクには1台分のサーバー情報が記載され、サブスクリプションURLからは通常、複数のサーバーと関連情報を取得できます。Configファイルにはルールや設定動作が記載されています。それぞれ用途が異なります。ルールファイルをサーバーのサブスクリプションとして扱ったり、サーバーの共有リンクを適合しない項目に入力したりすると、インポート失敗、リストが空になる、設定名だけ表示されて接続できないといった問題が起きることがあります。インポート前に、自分が利用しているサービスの提供元に情報の種類と入力先を確認してください。

Add Serverで手動入力する

HomeからAdd Serverを開き、手元の情報に合ったプロトコルを選んでから、アドレス、ポート、認証情報を入力します。アドレス欄には通常、ホスト名またはIPアドレスを入力し、Webページのパスは付けません。ポートにはサービス側が指定した接続ポートを入力します。メモは端末上で見分けるためのもので、変更しても接続先は変わりません。入力中は元の情報を手元に残し、各項目を照合してください。Webサイトのログインパスワードをサーバーのパスワードとして使わないでください。

プロトコルによって各項目の意味は異なります。Shadowsocksでは暗号化方式とパスワードを一致させる必要があります。VMessやVLESSではユーザー識別子や通信設定が必要になることがあります。TrojanではパスワードやTLSが関係します。WireGuardでは鍵、アドレス、接続先の情報を使います。必要な項目の数が異なるのは正常です。あるプロトコルの項目を別のプロトコルにそのまま当てはめないでください。資料に高度な設定項目がない場合は、必要性を確認し、推測で入力してハンドシェイクに失敗しないようにしましょう。

共有リンクまたはQRコードからインポートする

共有リンクをすでに持っている場合は、クライアントが対応している方法でインポートすると、手入力のミスを減らせます。QRコードも情報を伝える方法の一つにすぎません。スキャン後は項目を開き、種類、アドレス、認証情報を確認してください。スクリーンショットのQRコードは、切り抜かれていたり、縮小されて読み取りにくくなっていたりする場合があります。読み取れない場合は元のテキスト情報を入手し、判読できない文字を推測で補わないでください。保存後、Homeに項目が表示されたことを確認します。

リンクの先頭部分からプロトコルを判別できる場合がありますが、それだけですべての項目がそろっているとは限りません。共有リンクのエンコード、特殊文字、クエリパラメーターは省略せずに保持してください。チャットアプリで自動的に折り返されても、リンクに改行が含まれているとは限りません。コピー時に文末の句読点が混ざらないよう注意してください。個別の共有リンクとサブスクリプションURLの違いは、共有リンクの形式についてを確認し、この章に戻って各項目を照合してください。

既存のサブスクリプションを追加・更新する

自分が利用しているサービスの提供元から、完全なサブスクリプションURLを取得してください。Add ServerでSubscribeを選び、URLを入力して保存した後、更新を実行します。URLのパスやクエリパラメーターは識別に使われることがあるため、短くする目的で末尾を削除しないでください。更新後は、サブスクリプション名が表示されるかだけでなく、グループとサーバー項目も確認します。名前が保存されても内容が取得されていなければ、インポートは完了していません。初回更新に失敗しても、すぐに利用中の項目を削除しないでください。

サブスクリプションの更新ではネットワークリクエストが発生します。URLの期限切れ、アカウントの状態変化、基本ネットワークの問題、想定外の応答などが原因で失敗することがあります。以前の項目が残っている場合は、削除せずにエラーを記録し、URLにアクセスできないのか、ログインページが返されるのか、内容を解析できないのかを切り分けてください。更新に成功しても接続テストが完了したことにはなりません。サーバー一覧を取得できたことを示すだけなので、実際に使えるかは後の章で確認します。

サブスクリプションから作成されたサーバー項目を手動で変更する場合、次回の更新で上書きされる可能性があります。ローカルでの変更を長期的に残したい場合は、目的と元の値を記録し、独立した項目を作成するのが適切か確認してください。同じサブスクリプションを複数回インポートして個別に名前を変えるのは避けましょう。更新後にどのグループが有効か分かりにくくなります。管理時は入手元が明確なメイングループを一つ残し、新しいグループでの動作を確認してから古いグループを整理してください。問題の切り分け中に比較対象を失わないようにしましょう。

インポート後、テストするサーバーを一つ選び、所属グループとメモを記録してからGlobal Routingを設定してください。この時点では情報がそろっていることを確認すれば十分です。過去の設定をすべて一度にインポートする必要はありません。リストが空の場合は、インポートする情報の種類とサブスクリプションの更新状態を確認します。項目があるのに接続できない場合は、プロトコル設定を確認してください。「情報を取得できていない」と「取得した情報で接続できない」を分けて考えると、見当違いの操作を防げます。

Global Routingの3つのモード

Global Routingはクライアントが通信をどう処理するかを決める設定であり、サーバー一覧の並び替えではありません。画面のConfig（設定）、Proxy（プロキシ）、Direct（直接接続）はそれぞれ異なるルーティングモードを表します。選択する前に、サーバー接続を確認したいのか、ルールによる振り分けを確認したいのかを明確にしてください。同じサーバーでもモードが異なればアクセス結果が変わることがあります。問題を記録する際は、選択したサーバーとそのときのGlobal Routingを併記してください。

Configでルールによる振り分けを行う

Configを使う前に、Config画面で現在選択されているファイルを確認してください。複数のファイルをインポートしても、同時に有効になるわけではありません。選択されていないファイルを編集しても、現在の接続には反映されません。まずファイル名を記録し、ルールの順序とポリシー名を確認します。リモート設定がほかのリソースを参照している場合、そのリソースの取得に失敗すると、ファイルがあってもすべてのルールが利用可能とは限りません。問題が起きたら、見慣れたファイル名かどうかだけで判断せず、内容を確認してください。

ルールは通常、上から順に照合され、最初に一致したルールで処理方法が決まります。対象を限定するルールは広い範囲に適用されるルールより前に置き、最後にフォールバック用のルールを配置します。範囲の広いルールを先に置くと、後続の細かなルールに一致しないことがあります。以下はルール部分の基本構成を示す例であり、完全なConfigやサーバー情報は含みません。使用前にコピー上で現在の設定にあるポリシー名を確認し、既存ファイルをそのまま上書きしないでください。

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

この例では、指定したドメイン、指定ドメインのサフィックス、ローカルアドレスの範囲、地域判定の順に処理し、どのルールにも一致しない対象を最後にPROXYへ送ります。例のドメインは説明用であり、実際の用途にも同じポリシーを使うべきだという意味ではありません。PROXYやDIRECTなどのキーワードは変更しないでください。独自のポリシーグループを使うConfigでは、ルール末尾に実際に存在するグループ名を指定します。存在しない名前を指定すると、ポリシーを実行できないことがあります。

照合対象ごとにルールを理解する

DOMAINは完全一致するドメインを、DOMAIN-SUFFIXは指定したドメインとそのサブドメインを、DOMAIN-KEYWORDはドメインに含まれるキーワードを照合します。キーワードの範囲は想定より広くなることがあるため、使用前に意図しない一致がないか確認してください。IP-CIDRとIP-CIDR6はIPアドレスの範囲を照合し、GEOIPはIPアドレスの地域情報を利用します。FINALは、それ以前のルールに一致しなかった対象を処理します。ドメインルールが対象とするのはホスト名です。DOMAINの後ろにWebページのパス全体を入力しないでください。

ドメインの名前解決は、アドレスを使うルールの判定に影響します。同じドメインでも複数のアドレスに解決される場合があり、キャッシュやネットワークの変化によって結果が変わることもあります。そのため、昨日は一致したのに今日は一致しないからといって、ルールのテキストが変更されたとは限りません。確認時は、現在のリクエストのドメイン、名前解決の結果、実際の一致記録を照合してください。USER-AGENTのようなルールは、該当するリクエスト情報を取得できることが前提です。すべての暗号化通信からアプリの動作を完全に識別できるとは限りません。

ProxyとDirectで原因を切り分ける

Configのルールによってリクエストが誤った経路へ送られている可能性がある場合は、一時的にProxyに切り替え、同じ対象を再度テストしてください。Proxyでは成功しConfigでは失敗する場合、まず現在のConfig、該当ルール、ポリシーの指定先を確認します。サーバー情報をすべて入力し直す必要があるとは限りません。どちらのモードでも失敗する場合は、サーバー、認証情報、基本ネットワークを引き続き確認してください。テスト後は元のモードに戻し、一時的な調査用設定を常用しないようにしましょう。

Directは通常の直接接続経路が機能しているかを調べる際に使えますが、すべてのネットワークからあらゆる接続先へ直接アクセスできるとは限りません。Directで失敗しても、それだけでクライアントに問題があるとは判断できません。基本ネットワークと接続先への到達性を確認してください。比較する際は、端末、接続先、テスト時刻をできるだけそろえます。ネットワークとモードを同時に変えないでください。一度に変更する条件を一つにすると、どの設定が結果に影響したか判断しやすくなります。

ルールを調整した後は、直接接続される想定の対象とプロキシ経由になる想定の対象を一つずつ使って確認し、実際の一致記録も確認してください。Webページが表示されても、すべての振り分けが想定どおりとは限りません。変更前にConfigのコピーを保存し、変更後は今回の対象だけを確認して、問題がないことを確かめてから範囲を広げてください。ルールキーワードの簡単な説明は用語集をご覧ください。

接続と確認

接続は段階を分けて確認します。まず端末が基本ネットワークにつながっていること、次にクライアントの状態、最後に実際のリクエストが想定した経路を通っていることを確認してください。Homeのスイッチがオン、システムにVPNアイコンが表示、サーバーの遅延テストに結果が表示、という各状態はそれぞれ異なることを示します。どれか一つだけで、すべてのアプリが使えるとは判断できません。テストでは、繰り返しアクセスできるよく知った接続先を選びます。サーバー、ルール、ネットワークを同時に変更すると、結果を解釈できなくなります。

再現可能な手動接続を一度行う

自動接続を停止し、現在のネットワーク、選択中のサーバー、Global Routing、Configファイルを記録します。Homeの接続スイッチをオンにし、状態が安定するまで待ちます。すぐに切断される場合は、権限の確認、システムエラー、ほかのネットワーク接続との競合がないか確認してください。この段階でサーバーを何度も切り替えないでください。クライアントが安定して動作していない状態でサーバーを一つずつテストしても、結果を比較しにくくなります。まず端末の権限や起動時の問題を解決してください。

状態が安定したら、ブラウザでテスト対象にアクセスし、実際に使うアプリも確認してください。アプリによっては古い接続を再利用したり、独自の名前解決方法を使ったり、キャッシュを保持したりするため、ブラウザで成功してもすべてのアプリが同じ状態とは限りません。すでに開いていたアプリは、進行中のリクエストを終了してから再度開いてください。接続を維持するサービスでは接続し直して動作を確認し、設定変更前から残っていた接続を新しい設定の結果と混同しないようにします。

Connectivity Testの結果を正しく理解する

Connectivity Testは、現在のテスト条件で接続状況を比較するための機能です。テスト方法、接続先、ネットワークの種類、サーバーの負荷によって結果が変わります。表示された時間は長期的な性能を保証するものではなく、ダウンロード速度とも異なります。サーバーを比較する際は、同じ方法を使い、なるべく近い時間にテストしてください。テスト失敗は接続先に到達できない、またはサーバーがその方法に対応していないことが原因の場合もあります。実際のアクセス結果と合わせて判断し、単一の結果だけで項目を削除しないでください。

遅延が短いのにWebページを開けない場合は、リクエストに別の通信方式が必要か、認証に問題がないか、ルーティング先が想定したサーバーかを確認してください。遅延が長くても安定して使える場合は、数値の順に並べるためだけにすべての設定を変更する必要はありません。リクエストが完了するか、頻繁に切断されるか、特定のネットワークだけで問題が起きるかを確認するほうが有用です。更新を何度も押すより、テスト条件を記録するほうが変化の原因を把握しやすくなります。

失敗した段階に合わせて確認する

すべてのサーバーで接続に失敗する場合は、まず基本ネットワーク、システム時刻、サブスクリプション情報が有効か確認してください。ネットワークのログインが未完了、端末の時刻が大幅にずれている、システム権限が取り消されているといった状態も接続に影響します。特定のサーバーだけ失敗する場合は、その項目のアドレス、ポート、認証情報、通信設定を確認し、利用中サービスの提供元に状態を問い合わせてください。一つの項目が失敗したからといってサブスクリプション全体を削除しないでください。ほかの項目は重要な比較対象です。

接続できてもドメインにアクセスできない場合は、名前解決の結果とDNS関連の設定を確認します。一部の接続先だけ失敗する場合は、ルールの一致状況、接続先の状態、特殊な接続方法が必要かを確認してください。証明書エラーが出た場合は、システム時刻、TLSのサーバー名、ネットワークが認証ページに切り替わっていないかを確認します。証明書の検証を無効にすることを、通常の対処方法にしないでください。認証エラーと証明書エラーは発生する段階が異なるため、元の警告を残して個別に対処してください。

Wi-Fiでは使えるのにモバイル通信では失敗する、またはその逆の場合は、ほかの設定を変えずに同じテストを繰り返してください。ネットワークによってUDP、長時間接続、特定のポートへの対応が異なることがあります。メモの変更では解決しません。まず問題がネットワークの変更に伴うのか、サーバーの変更に伴うのかを確認してから、関連するプロトコル設定を調べてください。サービス提供元に相談する場合は、ネットワークの種類とエラーが発生した段階を伝えれば十分です。サブスクリプションの認証情報全体を送る必要はありません。

「接続済みなのにインターネットに接続できない」場合

この現象は、次の4点に分けて確認します。クライアントが端末上で動作しているか、リモートサーバーに到達できるか、Global Routingが正しいか、DNSとルールが対象のリクエストに合っているかです。この順に確認すると、サーバーの認証に失敗しているのにルールを何度も変更したり、ルールの誤判定なのに再インストールしたりするのを防げます。詳しい確認手順は接続スイッチがオンでもインターネットに接続できない場合の対処法、よくある質問はFAQをご覧ください。

確認が終わったら、Global Routing、選択中のConfigファイル、一時停止していた自動接続条件など、一時的に変更した設定を実際の利用状態に戻します。いったん切断してから再接続し、以前の接続のキャッシュによる偶然の成功ではないことを確認してください。長時間使った後にだけ問題が起きる場合は、発生前にネットワークを切り替えたか、画面をロックしたか、サブスクリプションを更新したかも記録します。こうした経緯は、一度のテスト結果より役立つことがあります。

特定の接続先にアクセスできたからといって、匿名性やプライバシーの範囲全体を確認できたとは限りません。クライアントは設定に基づいて接続を処理しますが、実際の経路はシステム、ネットワーク、接続先のアプリにも左右されます。このマニュアルで確認するのは、設定と実際のリクエストが一致するかどうかです。アイコン一つから過度な結論を導かないでください。テストの範囲を明確にすると、後から同じ問題を再現しやすくなります。

Dataの通信量とリクエスト記録

Dataでは、クライアントが記録できる通信量や接続状況を確認し、現在の設定と照らし合わせます。まず画面に表示された集計範囲と単位を確認してから数値を読み取ってください。端末のシステム、クライアント、サービス提供元で集計方法が異なる場合があります。数値が完全に一致しないからといって、いずれかに問題があるとは限りません。トラブルの確認では、累計値だけでなく、テスト前後の変化、リクエストの有無、実際に使われた経路を確認してください。

通信量・速度・遅延を区別する

累計通信量は一定期間のデータ量、リアルタイム速度は単位時間あたりのデータの変化、遅延はテストの往復にかかった時間を表します。それぞれ示す内容が異なります。通信量が増えたことは、集計対象の範囲でデータが通過したことを示しますが、Webページの読み込み完了を示すものではありません。瞬間的な速度が低くても、アプリが一時的にリクエストを送っていないだけの可能性があります。遅延テストに成功しても、大容量ファイルを安定して転送できるとは限りません。どれか一つの数値を、ほかの指標の代わりに使わないでください。

アップロードとダウンロードの両方が実際の利用に関係します。Webページを開く際にもリクエスト、認証、確認情報が送信されます。動画の再生前にもアップロード通信が発生することがあるため、アップロードがあるだけで異常とは限りません。バックグラウンドアプリ、システム同期、再試行のリクエストも通信量を発生させます。数値を確認する際は、起動中のアプリを把握してください。必要であればほかの処理を一時停止して、対象の操作を一度だけ行うと変化の原因を判断しやすくなります。一日分の合計で、直前数秒間のリクエストを説明しないでください。

小さな範囲のテストでルールを確認する

接続先が想定した経路を通っていない可能性がある場合は、現在の統計状態を記録してから、その接続先だけにアクセスし、利用可能な接続記録やリクエスト記録を確認します。接続先のドメイン、アドレス、適用されたポリシー、エラーが起きた段階を確認してください。見慣れたアプリ名が表示されたかどうかだけで判断しないでください。ページから複数のドメインにリクエストが送られる場合があります。メインページが開いても画像が読み込めない場合は、それぞれの接続を確認してください。実際に失敗したリクエストを特定してから、ルール変更を検討しましょう。

記録にDIRECTと表示されていて、本来はプロキシ経由のはずなら、Configに戻って現在のファイルとルールの順序を確認します。プロキシのポリシーが表示されているのに、準備されていないポリシーグループを参照している場合は、グループ内の選択状態を確認してください。ルールに一致しても、リモート接続の成功が保証されるわけではありません。その後に名前解決、ハンドシェイク、認証のエラーが起きることがあります。「なぜこの経路が選ばれたか」と「この経路でなぜ失敗したか」を分けて調べると、サーバーの変更とルールの追加を同時に行うより原因を整理しやすくなります。

対象の記録が見つからない場合も、そのアプリがクライアントを完全に迂回しているとはすぐに判断できません。以前の接続が再利用されている、記録の絞り込み条件が合っていない、ページのキャッシュによって新しいリクエストが発生していない、記録機能がその情報を対象としていない、といった可能性があります。まずリクエストを再読み込みするか、対象アプリを再起動してから、絞り込み範囲を確認してください。ログに情報がないことから分かるのは、現在の観察条件で記録を取得できなかったということだけです。そこから結論を広げないでください。

クライアントとサービス提供元で統計が異なる理由

サービス提供元の料金計算には、プロトコルのオーバーヘッド、送受信の両方向の通信量、特定の倍率、精算期間が含まれることがあります。一方、クライアントの統計はクライアント自身の観測範囲を反映します。集計の開始・終了時刻や単位が違うことも、数値の差につながります。利用量を比較する場合は、各集計の期間、リセット時刻、単位を確認してから同じ期間で比べてください。クライアントの数値はサービス提供元のアカウントに表示される残量の代わりにはなりません。サブスクリプション名に含まれる文字列だけで、リアルタイムの残量を判断しないでください。

Directとプロキシの通信量が異なる集計範囲に記録される場合もあります。Global Routingを切り替えた後の総量だけでは、ルールが想定どおりかどうかは判断できません。具体的なリクエスト記録と合わせて確認してください。アプリの更新、画像の先読み、接続の再試行によって、短時間で通信量が増えることもあります。異常な消費が疑われる場合は、まずほかの処理を一時停止してテスト時間を記録し、その後アプリを一つずつ再開してください。元の状態が分からなくなるような設定の削除は避けましょう。

記録する範囲と情報の公開に注意する

記録にはアクセス先のドメイン、時刻、アドレス、接続エラーが含まれる場合があるため、プライバシーに関わる診断情報として扱ってください。詳細な情報は問題の調査に必要な範囲だけ残し、終了後は通常の記録レベルに戻します。スクリーンショットを共有する前に、完全なサブスクリプションURL、認証情報、非公開のサーバーアドレス、個人のアクセス記録が写っていないか確認してください。タイトルを隠しただけでは本文の情報は隠れません。QRコードや展開した詳細項目も確認してください。

統計を消去する前に、比較用の記録を残す必要がないか確認してください。リセットすると新しいテストの開始点を作れますが、サーバーを修復したり、リモートアカウントの残量を増やしたり、ルールの一致方法を変更したりするものではありません。リセット後に時刻を記録し、決めた手順でテストすると結果を解釈しやすくなります。画面に必要な詳細が表示されない場合は、基本的な接続確認に戻ってください。存在しない数値を作ったり、空欄を推測で埋めたりしないでください。

確認が終わったら、「同じネットワークで、対象へのリクエストはConfigではDIRECTに一致し、Proxyに切り替えると成功した」のように具体的な結果を記録してください。「通信量がおかしい」とだけ書くより再現しやすく、次に確認すべき項目も分かります。Dataは診断の根拠の一つとして使い、Homeの状態、現在のConfig、実際のアクセス結果と合わせて確認してください。Dataだけで問題全体を診断しようとしないでください。

Settingsの主な項目

Settingsはクライアントの動作を調整する画面です。あらゆる接続エラーを直すためのスイッチではありません。まず動作する状態を維持し、必要に応じて項目を一つずつ変更してください。表示される項目はシステムや利用条件によって異なるため、現在の画面を基準に確認します。マニュアルで説明されているスイッチが見当たらない場合は、関係のない画面で同じ名前の項目を探さないでください。機能が現在のConfig、システム権限、その他の条件によって制御されていないか確認しましょう。

On Demandによるオンデマンド接続

On Demandは、設定した条件に応じてシステムの接続動作を開始します。Homeでスイッチを手動でオンにする操作とは異なり、必ず使えるサーバーを自動で選ぶ機能でもありません。有効にする前に、手動接続が安定して動作することを確認し、サーバー、Global Routing、Configが想定どおりであることを確認してください。そうしないと、既存の問題が自動接続のたびに繰り返され、接続と切断が続いたり、ネットワーク切り替え後に再び失敗したりすることがあります。

接続条件を設定する前に、どのネットワークで接続し、どのネットワークで停止したいのかを書き出してから、項目を一つずつ設定してください。Wi-Fi名を使う条件では、名前が完全に一致しているか確認します。似た名前のネットワークを同じものとして扱わないようにしましょう。有効にした後は、条件に入ったときと外れたときの動作をテストし、手動で切断した後に条件によって再接続されないか確認してください。一時的に自動接続を止める場合は、Homeのスイッチを何度も切り替えるだけでなく、On Demandの設定も確認します。

DNSと名前解決に関する設定

DNSはドメイン名をIPアドレスに変換します。名前解決に失敗すると、サーバーには接続できるのにWebサイトを開けないことがあります。設定を変更する前に、問題がドメイン名に限られるか確認してください。同じ接続先でもIPアドレスでのテストとドメイン名でのテストは条件が異なります。無関係なアドレスを比較対象にしないでください。Config内の設定が名前解決に影響することもあるため、Settingsの全体設定と現在のConfigファイルの内容を分けて確認します。原因を追跡できなくならないよう、両方を同時に変更しないでください。

特定のDNSサーバーのほうが速いと聞いたからといって、DNS設定をすべて置き換えないでください。DNSサーバーへの到達性、問い合わせ経路、キャッシュが結果に影響するため、現在のネットワークで適切かどうかは実際のリクエストで確認する必要があります。名前解決に問題がある場合は、まず元の設定値を記録し、現在のネットワークが正常か、Configが到達できないDNS方式を参照していないか確認してください。その後、必要最小限の変更を行います。変更後は関連する接続を再確立し、必要に応じて利用可能なキャッシュを更新します。接続のたびにキャッシュを消す必要はありません。

TLS、通信設定、証明書の注意点

TLS関連の項目は、暗号化接続の検証方法や確立方法に影響します。サーバーアドレス、サーバー名、証明書、システム時刻が一致している必要があります。IPアドレスで接続しても、資料で指定されたサーバー名の入力が必要な場合があります。ハンドシェイクに失敗した場合は、項目ごとに確認し、証明書エラーをそのまま無視しないでください。検証を無効にするとセキュリティ上の条件が変わります。日常的な対処として無効にしたり、サーバー側の設定が正しい証拠とみなしたりしないでください。

高度な通信設定は、自分がすでに持っているサーバー情報に基づいて入力してください。Host、パス、UDP関連の機能、プロトコルのオプションは、たくさん有効にすればよいというものではありません。クライアントとサーバーの設定が一致しないと、追加で有効にした項目が原因で失敗することもあります。特定の通信機能が必要な場合は、サーバーが明確に対応していることを確認してから項目を照合してください。ブラウザでのリクエストに成功しても、リアルタイムの音声・動画やほかのアプリに必要な機能まで満たしているとは限りません。

バックアップ、インポート、記録レベル

バックアップには何が含まれるか、事前に確認してください。サーバー項目、サブスクリプションURL、Configファイル、アプリの設定が、一つのエクスポート方法ですべて保存されるとは限りません。エクスポート内容を確認してから、自分で管理できる場所に保存します。サブスクリプションURLや鍵は機密情報です。バックアップファイルを一般的なルール例のように公開しないでください。復元時は端末による違いも考慮してください。特にネットワーク名、ファイルパス、システム権限は、別の端末でそのまま使えるとは限りません。

Configやバックアップをインポートすると、既存の内容が統合、置換、追加される場合があります。操作前に画面の説明を読み、現在の内容をコピーして保存してください。上書き範囲が分からないまま、過去のファイルを続けてインポートしないでください。復元後は、選択中のConfig、サーバーグループ、Global Routingを確認してから手動でテストします。見覚えのあるメモが表示されても、一部の項目が復元されたことしか分かりません。システムのVPN権限、自動接続の条件、すべてのリモートリソースが同期したとは限りません。

記録レベルを上げると、診断データが増えて整理にも手間がかかります。問題の特定に必要な範囲だけ記録してください。テスト終了後は不要な機密情報を含む記録を削除します。ただし、機密情報を伏せたエラーの要約は保存しておきましょう。説明できないログを長期間残すより、発生条件と再現手順を記録するほうが、システム更新や設定変更後の比較に役立ちます。

Settingsの調整後は、On Demandが想定した状態になっているか再度確認してください。テスト中に一時的に有効にした条件が、普段の接続に影響し続けるのを防げます。設定の意味が分からない場合は、複数のパラメーターを同時に試すより、元の値を保って該当する説明を確認してください。すぐに使える状態へ戻すには、使い方ガイドの基本手順に戻り、まず接続を確認してから高度な設定を一つずつ復元します。

日常のメンテナンスと問題の振り返り

日常のメンテナンスでは、動作する状態を保ち、変更点を追跡できるようにします。定期的にクライアントを再インストールする必要はありません。アプリ、サブスクリプション、ルールの更新を分けて記録してください。アプリの更新ではクライアントのプログラムが入れ替わり、サブスクリプションの更新ではサーバー情報が更新され、ルールの更新ではルーティングの判定が変わります。それぞれ独立して行われるため、更新後に問題が起きた場合は、どの層に変更があったか確認してください。すべてを単に「更新で壊れた」とまとめないようにしましょう。

更新する順序を決める

iPhone / iPad版のアプリはApp Storeから更新します。Mac、Windows、Android、Linux版は当サイトのダウンロードページから対応するインストーラーを入手してください。パソコンを更新する前に起動中のアプリを終了し、必要な設定を保存しておきます。インストール後はシステムの権限と接続状態を再確認してください。Androidで今回のインストール元を許可するよう求められた場合は、ファイルが当サイトから入手したものであることを確認し、インストール後にそのインストール元の権限を取り消せます。更新を理由に、ほかのアプリのインストール権限まで広げないでください。

Macの更新後も、チップに合ったバージョンか確認してください。システムによってブロックされた場合は、第1章の手順に従います。WindowsでSmartScreenが表示されたら、まずファイルの入手元を確認し、「詳細情報」から「実行」が許可されているか確認してください。Linuxでは同じパッケージ形式とパッケージ管理方法を使うと、変更を追跡しやすくなります。別の形式に切り替える場合は、古いインスタンスが起動したままになっていないか確認してください。デスクトップのショートカットが、ダウンロードした新しいアプリではなく古いファイルを起動することがあります。

サブスクリプションは、基本ネットワークが安定しているときに更新してください。更新前に利用中のサーバーのメモを記録し、更新後に項目が残っているか、設定値が変わっていないか、選択中の項目が切り替わっていないかを確認します。サブスクリプションの内容は、利用中のサービス提供元が管理します。名称が変わっても、クライアントに問題があるとは限りません。古い項目が消えた場合は、更新が完了したか、アカウント情報に変更があったかを確認してください。有効性を確認できない過去の設定値を、すぐに手動で追加しないでください。

ルール変更前に元に戻せる状態を残す

ルールを変更する前に、現在動作しているConfigをコピーして、用途が分かる名前で保存し、変更の理由も記録してください。一度に変更するのは、対象一つまたは明確な問題一つに限ります。テストを終えてから次に進んでください。リモートConfigをインポートする場合は、DNS、ポリシーグループ、外部リソースの参照を確認し、ルールの数だけで判断しないでください。設定が多いほど現在の用途に適しているとは限りません。内容を理解していない設定が、ローカルネットワークへのアクセスやほかのアプリの通信経路を変えることがあります。

問題が再発した場合は、確認済みのConfigに戻し、サーバーとネットワークは変えずに同じ接続先へアクセスしてください。正常に戻る場合は、新旧のルールと名前解決の設定を比較します。依然として失敗する場合は、サーバーの状態とネットワークの条件を確認してください。設定を元に戻すことは原因を切り分ける方法であり、それだけで原因が確定するわけではありません。Configの切り替えと同時にサブスクリプションを更新し、ネットワークやサーバーも変更すると、何が接続を回復させたのか分からなくなります。

端末の買い替え・再インストール前に準備する

端末を買い替える前に、必要なサーバー情報、サブスクリプションURL、Configファイルをバックアップし、実際に読み取れることを確認してください。システムの移行でVPN権限が自動的に復元されるとは限りません。初回接続時に再度許可が必要になる場合があります。iPhone / iPadでは、購入時と同じアカウントを使い、購入済み項目からアプリを復元します。iPhone / iPad版はApp Storeで$2.99の買い切り、Mac / Windows / Android / Linux版は無料です。後者は当サイトから対応するインストーラーを再度入手してください。

サーバー名だけが写ったスクリーンショットを唯一の記録にしないでください。通常、認証情報や通信設定を復元するには情報が足りません。バックアップは、利用中のサービス提供元でアカウント情報を保管する代わりにはなりません。端末を紛失した場合やサブスクリプションURLの漏えいが疑われる場合は、利用中のサービスの管理画面で認証情報を処理してから、新しい端末の情報を更新してください。端末上の項目を削除しただけでは、リモート側の認証情報は自動的に無効にならず、漏えいしたURLも使えなくなりません。

問題を調べるための最小限の記録を作る

役立つ問題記録には、どのネットワークで起きたか、何を操作したか、想定した結果、実際に表示された内容、直近で行った明確な変更を含めます。特に名前解決、接続、認証、証明書の問題では、エラーの原文を残すことが重要です。スクリーンショットが必要な場合は、機密情報を伏せてから保存してください。完全なサブスクリプションURL、共有用QRコード、鍵を公開の場に載せたり、障害と関係のない個人のアクセス履歴を添付したりしないでください。

1. 基本ネットワークに戻り、端末自体が通常どおりインターネットに接続できることを確認します。
2. Homeで現在選択しているサーバー、Global Routing、Configを確認します。
3. 同じ接続先に再現可能なリクエストを一度送り、Dataの記録と照らし合わせます。
4. 条件を一つだけ変更し、変化を記録してから、設定を維持するか元に戻すか決めます。
5. 問題が解決したら、自動接続と記録レベルを元に戻し、機密情報を伏せた調査結果を保存します。

さらに確認が必要な場合は、簡単な疑問はFAQ、ルール名やプロトコル項目は用語集、初めての操作は使い方ガイドをご覧ください。サーバー情報やアカウントの状態が原因と分かっている場合は、クライアントの無関係な設定を変更し続けるのではなく、利用中のサービス提供元に確認してください。このマニュアルでは設定方法を説明しますが、接続サービスやサブスクリプションは提供していません。

メンテナンス完了の目安は、すべてのスイッチを変更したことではありません。現在の設定の用途が明確で、接続を再現でき、機密情報を安全に保管し、一時的なテスト状態を元に戻せていることです。同じ問題が再発した場合は、該当する段階からこの8つのステップを確認すればよく、インストールからやり直す必要はありません。変更を説明可能な範囲に絞ると、同じ操作を繰り返さずに済み、端末やネットワークが変わった後も元の使い方に戻しやすくなります。