公式マニュアル / 項目別ガイド
Shadowrocket 完全ガイド
入手、許可、インポート、ルーティング、メンテナンスを順に確認します。現在の段階を把握してから、該当する項目を操作してください。
操作の流れや設定値の範囲、トラブルシューティングの順序を解説します。初回接続を終えた後、項目ごとに確認したい場合にご覧ください。一度接続するまでの手順ははじめにをご覧ください。特定の項目やルールを確認する場合は、本ページの該当章に戻ってください。ご自身で用意したサブスクリプションまたはサーバー情報をお持ちであることを前提としています。
- 対応デバイス iPhone / iPad
- 入手先 App Store
- 閲覧順 8段階
段階 01 / 入手したアプリを確認
App Storeでの入手と正規品の確認
ShadowrocketはAppleプラットフォーム向けの有料・クローズドソースの商用アプリで、主にiPhoneとiPadで利用できます。入手前に、クライアント、サーバー、設定ファイルを区別しましょう。クライアントは接続を確立してルールを処理し、サーバーはお手元の接続先を提供し、設定ファイルは通信の処理方法を定めます。クライアントを購入しても、残りの2つが自動的に用意されるわけではありません。不足しているものを確認してから進め、購入完了を接続可能な状態と混同しないようにしてください。
ダウンロードガイドからApp Storeへ
App Store正規版の入手ガイドを開き、ページ内のストアボタンから製品ページへ進みます。アプリ名がShadowrocketであることを確認し、続けてデベロッパ情報もご覧ください。検索結果の略称やアイコンの色だけで判断しないでください。似た名前の別製品が表示される場合があります。このサイトの入手ガイドでは購入と確認の方法を説明し、本マニュアルでは確認後の設定を解説します。別の入手先は案内していません。
正規品かどうかは、デベロッパがShadow Launch Technology Limitedであること、公式アイコンが本サイトのヘッダーに表示されているアイコンと一致すること、製品ページのURLにアプリID 932747118が含まれることの3点を確認してください。アイコンだけでは確認できません。検索結果から開いたページでいずれかが一致しない場合は、ページを閉じて入手ガイドに戻り、そこから開き直して購入を判断してください。
価格と互換性を確認する
Shadowrocketは買い切り型です。米国ストアでの参考価格は2.99米ドルですが、実際の価格、税金、決済通貨はApp Storeの製品ページと購入確認画面でご確認ください。ストアの地域が異なる価格を金額だけで比較することはできません。また、マニュアルに記載された参考価格は支払いの証明にはなりません。ページに再ダウンロードのアイコンが表示されている場合は、現在のアカウントに購入履歴があるか確認し、重複購入を避けてください。
システム要件は、必ずApp Storeの製品ページに記載された内容をご確認ください。購入前に互換性の項目でお使いのデバイスとシステムを確認し、空き容量も確かめてください。Mac、Apple TV、Apple Visionの互換性と購入対象も、App Storeの記載が基準です。これらのデバイスもApp Storeから入手します。本ページの以降の手順はiPhoneとiPadを対象としており、ほかのデバイスの操作場所を当てはめないでください。
インストール後に準備する
App Storeで購入または再ダウンロードしたら、デバイスのホーム画面にアプリが表示されるまで待ち、Shadowrocketを開きます。この時点でリストが空でも、サーバーをまだインポートしていない状態であり、購入失敗を意味するものではありません。お手元の有効なサブスクリプションURLまたは個別サーバー情報を用意してください。支払い情報をサーバーのパスワード欄に入力したり、購入に使ったアカウントのパスワードを接続情報として使ったりしないでください。
接続情報には通常、アドレス、ポート、プロトコル、認証情報が含まれます。具体的な組み合わせはサーバーによって異なります。サブスクリプションURLだけをお持ちの場合は、クライアントで読み込むためのURLであり、サービス提供元の管理画面へのログインURLではないことを確認してください。用途が不明な場合は、ご自身のサービス提供元に項目の説明を確認しましょう。マニュアルのサンプルドメインは構造の説明用であり、実際のサービスのテストには使えません。既存の接続情報をサンプル値で置き換えないでください。
デバイスの買い替えや再インストール時は、まずApp Storeのアカウントの購入済み項目からShadowrocketを探してください。購入履歴とアプリ内データは別のものです。アプリを再ダウンロードできても、サーバー、設定、統計データが復元されるとは限りません。復元前に有効な情報を保管していることを確認してください。古いデバイスがまだ使える場合は、サブスクリプションの入手元と設定のバックアップを整理してから新しいデバイスに移行し、最後に古いデバイスのデータを整理します。
この段階の完了条件は、製品の正規性を確認し、アプリをインストールし、有効な接続情報を用意できていることです。ストアで互換性がないと表示される、購入が完了しない、購入履歴が見つからない場合は入手段階の問題です。まず購入済みアプリの復元方法またはFAQをご覧ください。ルーティングルールの変更ではストアの問題を解決できません。これらの設定は購入やインストールに関係しないためです。
段階 02 / 許可の範囲を確認
初回起動とVPN構成の許可
初回起動後は、各画面の役割を確認しましょう。Home(ホーム)ではサーバーと接続状態を管理し、Config(設定ファイル)では設定ファイルを管理します。Data(通信量)では使用状況を確認し、Settings(設定)では関連項目を調整します。画面のレイアウトはデバイスやアプリの仕様変更によって異なる場合があるため、操作時は現在表示されているタブを確認してください。まず画面を見分けてから項目を探し、Config画面とGlobal RoutingのConfig設定値を混同しないようにしましょう。
システムによる許可の役割を理解する
Shadowrocketで接続するには、システムによるVPN構成の管理が必要です。初めて接続スイッチをオンにすると、VPN構成の追加を許可するようシステムから求められる場合があります。アプリ名とメッセージを確認し、現在の操作に対するものと確かめてから許可し、システムの指示に従ってデバイスの認証を完了してください。この操作でアプリによるネットワーク接続が許可されますが、サーバーが利用可能になるわけではなく、特定のWebサイトへのアクセスがプロキシ経由になる保証もありません。
その場で許可を取り消した場合は、アプリに戻り、接続スイッチを短時間に何度も切り替えないでください。デフォルトサーバーが設定されていることを確認してから、接続を再度開始し、表示されるメッセージを確認します。デバイスが組織の管理下にある場合、VPN構成の追加が制限されていることがあります。その場合はデバイスの管理ポリシーを確認してください。権限の問題に対して、システムのネットワーク設定をすべて削除する操作を繰り返さないでください。ユーザーによるキャンセル、システムの制限、接続情報の誤りのどれに該当するか、まず確認しましょう。
許可した後は、システム設定で「VPN」を検索し、該当する構成が表示されることと現在の状態を確認できます。システムメニューの場所は変更されることがあるため、デバイスで検索した結果を基準にしてください。ステータスバーの表示だけで接続の成否を判断しないでください。画面のレイアウトによって表示方法が異なる場合があります。アプリ内のスイッチ、システムの接続状態、その後の実際のアクセス結果をあわせて確認してください。
必要な許可と操作時に求められる許可を区別する
Scan QR Code(QRコードをスキャン)を使う際、カメラの使用許可を求められる場合があります。ご自身のサーバーまたはサブスクリプションのQRコードをスキャンするときに必要な許可です。カメラを許可していない場合でも、既存のURLを使うか情報を手動で入力できます。カメラの問題ですべてのインポート方法が使えなくなるわけではありません。QRコードには認証情報が含まれる場合があります。スキャン前に入手元を確認し、インポート後に種類とアドレスを確認してください。QRコードの画像を公開しないでください。
クリップボードからURLを読み取る際、システムにペースト関連のメッセージが表示される場合があります。まず、インポートする内容をコピーしてから、アプリ内のペーストまたはインポート操作を行ってください。クリップボードに説明文、改行、空白が混入すると、解析に失敗することがあります。メッセージを避けるためにサブスクリプションURLを公開Webページに置かないでください。元の情報を確認して完全な内容をコピーし、現在の画面にあるインポート機能を使ってください。
ファイルやクラウド上のデータをインポートできるかどうかは、選択した入手元とシステムの許可によります。ファイル選択画面が開いても、選択したファイルが現在のインポート方法に適した形式とは限りません。サブスクリプション、設定ファイル、サーバーのQRコードは用途が異なるため、それぞれに対応する機能を使ってください。ご自身のクラウドバックアップを使う場合は、ファイル名と用途を確認してから、現在の設定を上書きするか判断します。
初回起動時の確認順
初回のトラブルシューティングでは、On Demand(オンデマンド接続)の状態を把握し、手動スイッチで接続を制御することをおすすめします。自動接続の条件が有効になっていると、接続を切ってもすぐ再接続されることがあります。その場合は、アプリの異常と判断する前にOn Demandを確認してください。手動接続が安定してから、必要に応じて自動接続の条件を設定し、ネットワーク切り替え時の動作を確認します。
デバイスにほかのVPN接続がある場合は、システム設定で現在どの構成が接続を制御しているか確認してください。複数の接続設定を同時に変更し、どれが有効か推測するのは避けましょう。元の状態を記録し、今回のテストに関係のない接続を一時的に停止してから検証します。テスト後は必要に応じて元に戻してください。組織が提供するネットワーク構成はデバイスの管理要件に従い、ほかの用途に影響しないよう、むやみに削除しないでください。
この段階を終えると、現在の画面、VPN構成の追加が許可されているか、On Demandが有効か、インポート時にどの追加許可が必要かを説明できる状態になります。アプリは開くがサーバーがない場合は次の章へ進み、サーバーがあるのにシステムが接続を拒否する場合は、まず許可の問題を解決してください。許可に問題がないのに接続できない場合は、認証情報とネットワークを確認します。同じ操作を繰り返す前に、問題のある段階を見極めましょう。
段階 03 / 接続先を準備
サーバーの追加とSubscribe
サーバーは個別の接続先、サブスクリプションは複数のサーバー情報を取得するための入口、Configはルーティングや関連設定を定めるものです。相互に連携しますが、置き換えることはできません。まず手元の情報の種類を確認しましょう。プロトコル、アドレス、ポート、認証情報がある場合は手動で追加できます。クライアント用の共有リンクがある場合は、対応するインポート機能を使います。サブスクリプションURLがある場合は、Subscribe(サブスクリプション)の機能を使ってください。ファイルの拡張子だけで内容を判断しないでください。
Add Serverの項目を確認
Homeで追加機能を開き、Add Server(サーバーを追加)を選択します。まずType(種類)を選び、情報に沿ってAddress(アドレス)とPort(ポート)を入力し、最後にプロトコルに必要な認証情報や通信パラメータを確認してください。種類によって各項目の意味が変わるため、入力後に種類を変更すると設定漏れが起きやすくなります。保存したらリストに戻り、対象を開き直して自動入力やクリップボードの内容で上書きされていないか確認します。
Addressには通常、ドメイン名またはIPアドレスを入力し、Portにはポート番号だけを入力します。項目で完全なURLを求められている場合を除き、プロトコルの接頭辞、パス、ポートをまとめてAddressに入力しないでください。サーバー情報に記載されたドメイン名、TLSの検証名、通信時のHostは同じ場合も異なる場合もあります。推測で同じ値にせず、資料に沿って個別に入力してください。認証に失敗した場合は、まず項目の対応関係を確認し、文字列が欠けていないか確認します。
| Type | 重点確認項目 | 混同しやすい点 |
|---|---|---|
| Shadowsocks | アドレス、ポート、暗号化方式、パスワード | 暗号化方式はサーバーと一致させる |
| VMess / VLESS | アドレス、ポート、UUID、通信方式、TLSパラメータ | UUIDは通信方式の設定の代わりにはならない |
| Trojan | アドレス、ポート、パスワード、TLSパラメータ | 証明書の検証名と接続先アドレスは異なる場合がある |
| Hysteria2 | アドレス、ポート、認証情報、TLSパラメータ | 現在のネットワークで該当するUDP通信が許可されているかも確認する |
この表は確認時の要点であり、各プロトコルのすべての設定項目を示すものではありません。追加の通信パス、Host、その他のパラメータがある場合は、ご自身のサーバー情報とアプリの現在の項目説明に従ってください。あるプロトコルのパスワードを別のプロトコルのID項目にそのままコピーしないでください。また、名前の不一致を隠すために証明書の検証を無効にせず、まず設定を修正してからサーバー側の調整が必要か判断します。
既存のサブスクリプションをインポート
サブスクリプションURLをお持ちの場合は、追加手順でSubscribeを選択し、対応する欄にURL全体を入力して保存し、更新結果を待ちます。URLにはアカウントを識別するパラメータが含まれる場合があり、機密情報として扱う必要があります。URL全体を公開の掲示板に貼り付けたり、覚えやすくするためにクエリパラメータを削除したりしないでください。以下はURLの構造を示す例で、接続可能なサービスではありません。
https://example.com/sub?token=xxxx
更新後はHomeに戻り、サブスクリプションのグループとサーバーの項目が表示されていることを確認してから、種類と名前がご自身の情報に合っているか確認してください。項目数が増えたことは、内容が読み込まれたことを示すだけで、すべての接続先が利用できることを意味しません。更新に失敗した場合は、URLが完全か、サブスクリプションが有効か、現在のネットワークからURLにアクセスできるかを確認します。更新に成功しても項目が表示されない場合は、返された内容がアプリ対応のサブスクリプション形式か確認してください。
サービス提供元のアカウント管理ページをサブスクリプションURLとして登録しないでください。管理用のWebページには通常、ログイン画面や管理画面があり、サーバー一覧ではありません。インポート時に内容を認識できないと表示された場合は、同じURLを何度も別のグループとして追加せず、ご自身の情報ページに戻って用途を確認してください。重複登録では形式の問題は解決せず、デフォルトサーバーや更新元が分かりにくくなります。
QRコード、デフォルトサーバー、更新時の注意点
Scan QR Codeを使ったら、解析結果を確認してから保存してください。QRコードには個別サーバーが含まれる場合も、サブスクリプションの入口が含まれる場合もあります。QRコードだからといって用途を決めつけないでください。ご自身の古いデバイスから読み取る場合も、認証情報が変更されていないか確認します。スキャンに失敗した場合は、画像が鮮明か、端まで写っているかを確認してください。QRコードの一部を切り取って再試行したり、認証情報を含む画像を公開したりしないでください。
インポートが完了したら、Homeで対象サーバーの左側にある丸印をタップし、デフォルトサーバーに設定します。接続スイッチをオンにする前に、選択状態をもう一度確認してください。直前に編集した項目だけで接続先を判断しないようにしましょう。サブスクリプションの更新で項目が置き換わったり削除されたりする場合があるため、更新後はデフォルトの選択を再確認してください。遅延や地域の確認方法は、サーバーの選び方と遅延テストをご覧ください。
サブスクリプションの項目を手動で変更する前に、次回更新で変更が上書きされるか確認してください。個別にテストする項目を残す必要がある場合は、アプリの管理機能に沿って別途保存し、サブスクリプションとの関係を記録します。利用可能な接続先が1つしかない場合は、先に削除してから追加するのではなく、新しい情報を確認してから古い項目を整理してください。この段階の完了条件は、情報の入手元が明確で、項目がそろい、接続先を確実に選べることです。
段階 04 / 通信の経路を決定
Global Routingの3つのモードとルール
Global Routing(グローバルルーティング)は、今回の接続で通信をどのように処理するかを決定します。主なモードはConfig(設定)、Proxy(プロキシ)、Direct(直接接続)の3つです。サーバーを選ぶとプロキシ接続に使う接続先が決まりますが、すべてのリクエストがそこを経由するとは限りません。トラブルシューティングでは、デフォルトサーバー、ルーティングモード、現在の設定ファイルをあわせて記録してください。これらの前提が異なると、同じWebサイトでも結果を比較できません。
モードを選んでから結果を確認
| 画面上の設定値 | 主な意味 | 確認に適した内容 |
|---|---|---|
| Config | 現在の設定に含まれるルールや関連ポリシーに従って処理する | 指定した宛先が想定どおりのルールに一致するか |
| Proxy | プロキシを主なルーティング方法として使う | 選択したサーバーの基本的な接続能力を確認する |
| Direct | 直接接続する | 現在のネットワークでの直接アクセス結果と比較する |
ルールによる振り分けが必要な場合は、まずConfig画面でファイルの内容を確認して選択し、Global RoutingをConfigに設定します。設定ファイルをインポートしただけでは、現在使用中になっているとは限りません。Proxyでルールを変更してもアクセス結果が変わらない場合は、ルールの順番を何度も入れ替える前に、モードを確認してください。モードによって、ルールが現在の処理に適用されるかどうかが異なります。
画面によってはScene(シーン)も表示されます。これは設定済みの条件に応じて動作を組み立てる機能であり、上記3つのモードの意味を置き換える汎用ルールではありません。シーンを使う明確な理由がなければ、まず3つの基本モードで動作を確認してください。自動シーンとOn Demandが同時に関係する場合は、それぞれの条件を確認してから現在の状態が変わる理由を判断します。自動動作をすべてルールの適用に結び付けないでください。
ルールの順序とフォールバックを理解する
ルールは通常、上から順に評価され、最初に一致したルールで処理が決まります。具体的な対象を先に置き、より広い条件を後ろに置き、最後にFINALをフォールバックとして設定します。PROXYとDIRECTはルール内のポリシーキーワードで、画面上の設定値Proxy、Directとは表記が異なります。編集時は既存のキーワードの大文字・小文字とカンマの構造を保ち、ルール欄に日本語の説明を書き込まないでください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
この例では、例示用ドメインとそのサブドメインにPROXYを適用し、指定したプライベートアドレス範囲をDIRECTで処理します。次にGEOIP条件に該当するアドレスを処理し、最後に残りの通信をPROXYに振り分けます。これは順序を理解するための.conf断片であり、あらゆるネットワークで使える完全な設定ではありません。既存ファイルに追加する場合は、既存の[Rule]セクションを編集し、ほかの必要なセクションを残してください。フォールバックルールを重複して追加しないでください。
| キーワード | 照合対象 | 使用時の注意 |
|---|---|---|
| DOMAIN | 完全一致するドメインを指定 | サブドメインも対象にする場合は範囲を別途検討する |
| DOMAIN-SUFFIX | ドメインのサフィックスと該当するサブドメイン | 通常、キーワード一致より範囲を限定しやすい |
| DOMAIN-KEYWORD | ドメインに含まれるキーワード | 範囲が広いため、意図しない一致がないか確認する |
| IP-CIDR / IP-CIDR6 | IPv4 / IPv6のアドレス範囲 | 実際の宛先アドレスとアドレスファミリーを確認する |
| FINAL | 前のルールに一致しなかった通信 | ルールの末尾に置く |
変更範囲を限定する
ドメインルールにはWebページのパスやURL全体を入力しません。Webアドレスに含まれるプロトコルの接頭辞、スラッシュ以降のパス、クエリパラメータは、DOMAIN-SUFFIXのドメイン欄に含める値ではありません。IPルールのno-resolveは、そのルールが追加のドメイン解決を引き起こさないようにする指定であり、設定全体でDNSの使用を停止する意味ではありません。対象が実際にはIPv6を使っている場合、IPv4のアドレス範囲だけを調べてもすべてのリクエストを説明できません。
変更前に現在の設定を複製し、目的を説明できる条件を一度に1つだけ追加してください。ファイルを保存して選択できることを確認したら、固定した対象でテストします。結果が想定と異なる場合は、先に評価されるルールに一致していないか、ページが別のドメインにもリクエストしていないか、既存のセッションが残っていないかを順に確認してください。ページを更新しただけでは既存の接続が残ることがあります。保存後に再接続してから、同じ条件で再テストしてください。
指定したWebサイトだけをプロキシ経由にする場合は、ドメインを明示したルールを使い、FINAL,DIRECTをフォールバックに設定できます。ただし、ページがログイン、画像、メディアなどの別ドメインにもアクセスする場合があるため、事前に把握してください。リソースが1つ失敗しただけで、範囲を説明できないほどキーワード一致を広げないでください。具体例は指定サイト向けConfigルールの例をご覧ください。まず最小限の変更を行い、実際のリクエストに応じて対象範囲を調整します。
段階 05 / 段階ごとに確認
接続スイッチとConnectivity Test
接続の確認は、システムの許可、サーバーへの接続、宛先へのアクセスの3段階に分けて行います。スイッチをオンにしただけでは、接続を開始したことしか分かりません。システムにVPN接続中と表示されても、すべての宛先にアクセスできるとは限りません。サーバーとルーティングモードを1つずつ固定し、再現可能なテストを行ってから確認範囲を広げてください。サーバー、ネットワーク、設定を一度に変更して得た結果では、どの変更が影響したか分かりません。
まず最短の接続経路を確認
Homeに戻り、対象サーバーの左側に選択マークがあることを確認してから、Global Routingを確認します。サーバーの基本的な利用可否を先に判断するには、元のモードを記録してから一時的にProxyでテストし、終了後は必要なConfigに戻してください。接続スイッチをオンにし、システムの許可に対応して状態が安定するまで待ちます。接続中にサーバーを何度も切り替えないでください。複数の試行の状態やエラーが混在します。
次にConnectivity Test(接続テスト)を実行し、現在の画面に表示される結果とエラーを確認します。このテストで確認できるのは特定のテスト処理であり、すべてのWebサイトへのアクセスを保証するものではありません。失敗した場合は、タイムアウト、名前解決エラー、認証関連のエラーのどれかを確認してください。成功した場合は、アクセス権があり、普段利用できる宛先も開いてみます。アプリ内テストと実際のアクセスは相互に補完するもので、どちらか片方だけで結論を出さないでください。
遅延テストも測定方法を区別する必要があります。接続の確立、プロトコルのハンドシェイク、特定リクエストの往復時間など、方法によって測定対象が異なるため、数値だけを直接比較できません。遅延が低くても継続的なダウンロードが速いとは限らず、混雑時も安定する保証はありません。同じネットワーク、テスト方法、時間帯をそろえて繰り返し確認してください。一度だけ極端に低い数値が出ても長期的な性能とは見なさず、タイムアウトだけで接続情報が恒久的に無効だと判断しないでください。
エラーの段階に応じて確認
スイッチがオンの状態を保てない場合は、システムでVPN構成が許可されているか、デバイス管理による制限があるか、ほかの接続構成が制御していないかを確認してください。スイッチは正常でもすべてのリクエストに失敗する場合は、アドレス、ポート、認証情報、プロトコルの種類を確認します。特定のWi-Fiだけで失敗する場合は、そのネットワークでWebログインが必要か確認し、モバイル通信と比較してください。ネットワークを切り替えたら再接続し、以前の状態のまま判断しないようにします。
認証関連のエラーでは、パスワード、UUID、その他のID情報を優先して確認し、コピー時に前後の空白や改行が入っていないか注意してください。接続タイムアウトの場合は、サーバーのアドレス、ポート、ネットワークからの到達性を確認します。TLS関連の問題では、検証名、デバイスの日付と時刻、サーバー情報を確認してください。TLSエラーが表示されても、すぐに検証を無効にしないでください。設定の不一致が示されている可能性があります。不一致を解消してから再テストします。
ProxyではアクセスできるのにConfigではできない場合は、クライアントを買い直すのではなく、ルール、ポリシー参照、DNS関連の設定を確認してください。DirectではアクセスできるのにProxyではできない場合は、選択したサーバーとその接続経路を重点的に確認します。どちらでも失敗する場合は、宛先サイト自体とローカルネットワークの問題を先に切り分けます。これらの比較で問題の範囲を絞れますが、デバイスやサービスが正常であることを単独で証明するものではありません。
一部だけ成功する場合と接続の残存を確認
Webページの文字は表示されるのに画像や動画が読み込めない場合は、ページのメインドメインだけでなく、リソースのリクエストも確認してください。ログイン後の移動先、メディア、APIは別のドメインにある場合や、異なる接続方法を使う場合があります。まずメインページと失敗したリソースが同じルーティングで処理されているかを確認してから、ルールの追加を検討してください。ブラウザーのキャッシュで古い内容が正常に見える場合があるため、新しいリクエストで現在の状態を確認します。
Wi-Fiからモバイル通信に切り替えた後は、既存の接続を再確立する必要がある場合があります。まず新しいネットワーク自体が使えることを確認し、接続を一度切ってから再接続し、同じテストをもう一度実行してください。Hysteria2などUDPを使うプロトコルでは、現在のネットワークが該当する通信をサポートしているかも確認します。ネットワークの制限を補うために、多数のプロトコル設定をむやみに変えないでください。ネットワークごとの差を記録し、ご自身のサービス提供元に確認しましょう。
さらに相談する場合は、デバイスのシステム、現在のネットワーク、サーバーのプロトコル、ルーティングモード、テスト対象、エラーの原文を整理してください。サブスクリプションURL、パスワード、UUIDなどの認証情報は削除します。「何をした後に何が起きたか」を記録すると、「接続できない」とだけ伝えるより役立ちます。初回接続の手順は初回接続の確認方法、よくあるケースはFAQをご覧ください。この段階の完了条件は、偶然ページが開くことではなく、再現可能な方法で確認できることです。
段階 06 / 統計の範囲を確認
Dataの通信量と使用量の見方
Data(通信量)は、アプリが記録したネットワーク活動を確認するための画面であり、通信事業者の請求画面ではありません。表示内容を読む際は、まず表示形式、集計対象、期間を確認してから数値を比較します。アップロードはデバイスから送信されたデータ、ダウンロードはデバイスが受信したデータです。累計値は一定期間の合計を示し、速度は特定時点または短い時間内の変化を示します。これらは相互に置き換えられず、1つの数値だけで接続状態を判断することもできません。
現在の統計表示を確認
Dataを開いたら、まず現在の表示形式を確認します。サーバー別表示では、どの接続先が通信を処理したかを確認します。アプリ別表示では、アプリが識別して分類できるリクエストの送信元を確認します。この2つは同じ請求内容の並べ替えではなく、識別範囲、分類方法、集計開始時点が異なる場合があります。集計方法を確認せずに、両方の行を合算したり、項目ごとに対応付けたりしないでください。
リストに明確に分類できない項目があっても、まずは現在の識別方法や接続記録の範囲によるものと考え、異常なアプリが存在すると決めつけないでください。システムサービス、バックグラウンド動作、アプリ内リクエストなどにより、名前が分かりにくくなることがあります。発生時刻、使用中のアプリ、接続状況をあわせて確認してください。表示名だけからリクエストの内容全体を推測することはできず、デバイス自体のアプリ権限の確認にも代わりません。
累計値を見る前に、表示に集計期間が記載されているか、手動でリセットしたことがあるか、アプリの再起動やデータ復元後も数値が引き継がれているか確認してください。明確な起点が表示されていない場合は、「今月の通信量」として扱わないでください。異なるデバイス間で数値が連続しているとも限りません。長期的に記録する場合は、確認開始時点と数値を自分で記録し、同じ条件で比較してください。根拠のない数値に請求期間の意味を持たせないようにしましょう。
請求額と異なる理由
通信事業者はネットワーク側の課金対象通信量を計測し、Dataはアプリが確認できる関連通信を集計します。プロトコルのオーバーヘッド、接続の維持、再送、同じ経路を通らないリクエストなどにより差が生じる場合があります。デバイスがWi-Fiとモバイル通信を切り替えている可能性もあり、異なる通信元の使用量を同じ請求期間の数値としてまとめることはできません。Dataは増減の傾向を確認するのに役立ちますが、実際の料金と利用枠は通信事業者の記録を基準にしてください。
サーバー側の使用量も、方向、請求対象の範囲、特定のセッションなどで集計方法が異なる場合があります。クライアントに表示された1つの数値から、サービス提供元の課金計算式を推定しないでください。差を調べる必要がある場合は、双方の開始・終了時刻、単位、通信方向をそろえてから、ご自身のサービス提供元に問い合わせてください。共通の集計方法がなければ、数値が一致しないだけではどちらかの誤りとは判断できません。
| 表示内容 | まず確認すること | 数値だけでは判断できないこと |
|---|---|---|
| スイッチはオンだが通信量が少ない | 新しいリクエストが発生しているか、Directやキャッシュが使われているか | 数値が少ないだけで接続失敗とは判断できない |
| アップロードが継続して増える | クラウド同期、ファイルのアップロード、バックグラウンド動作 | 通信方向だけで異常とは判断できない |
| 累計値が変化する | 表示形式、リセット操作、集計開始時点 | 現在の請求期間の使用量とは限らない |
操作を固定して増加量を確認
特定のアクセスで通信が発生したかを確認するには、テスト前の数値を記録し、明確な操作を1回行い、画面の更新後に増加量を確認してください。テスト中は、関係のない大容量ファイルの同期やメディア再生を一時停止して、バックグラウンドの影響を減らします。短時間の増加分を、直前に開いたWebページだけの通信量と決めつけないでください。バックグラウンドアプリが同時に通信している可能性があります。必要に応じて同じ操作を繰り返し、変化が一致するか比較します。
スイッチをオンにしても数値に変化がないからといって、アプリが停止しているとは限りません。ページがキャッシュから読み込まれた、ルールによりDirectで接続した、または新しいリクエストが発生していない可能性があります。逆に画面を操作していなくても、通常のバックグラウンド同期で数値が増える場合があります。判断する前にGlobal RoutingとConfigを確認し、対象通信が想定した経路を通るかを確かめてください。統計画面をルーティングの確認の代わりにしないようにしましょう。
瞬間的な速度の変動は短い時間内の観測であり、長期的な帯域幅を示すものではありません。動画のバッファリング、分割ダウンロード、短時間の接続では、速度が一度上がってから下がることがあります。接続性能を比較する際は、同じタスクと近いネットワーク条件を使い、キャッシュからの読み込みと完全なダウンロードを一緒に比較しないでください。速度の単位も確認しましょう。バイトとビットは異なる単位なので、表示単位を無視して数値だけを比較できません。
リセットする前に、必要な記録を保存し、リセットの対象範囲を確認してください。リセットで変更されるのは統計表示や関連記録であり、サーバー認証情報は初期化されず、接続の問題も解決しません。Dataのスクリーンショットを共有する場合は、個人アカウントやサーバーを特定できる情報を隠してください。表示内容の詳しい説明はDataの通信量表示の見方をご覧ください。この章の目的は集計方法を正しく理解することであり、統計を請求明細の代わりに使うことではありません。
段階 07 / 設定変更を管理
Settings、DNS、On Demand
Settings(設定)の項目は、明確な問題を解決するために変更し、すべてを順にオンにするのは避けてください。ネットワーク切り替え後に条件に応じて接続する、ドメインの名前解決を修正する、テスト方法を変更するなど、期待する結果を先に明確にし、関連する項目を探します。設定ファイルにも同様の設定が含まれる場合があるため、変更前に設定の入手元を区別してください。アプリ設定と現在の設定ファイルが同じ動作に影響する場合は、画面上の説明と実際のテストで適用関係を確認します。
On Demandの接続開始と停止
On Demand(オンデマンド接続)は、設定した条件に応じてシステムから接続を開始する機能であり、サーバー障害を直す汎用ボタンではありません。初めて設定する前に、手動モードで同じサーバーに接続できることを確認してください。その後、実際に必要な接続条件を設定します。ネットワークの種類、ネットワーク名、その他の条件は現在の画面で設定できる項目に従って入力してください。ほかの場所で見た項目名を、お使いのデバイスにもあると決めつけないでください。
設定後は、条件に一致する場合と一致しない場合の両方をテストし、ネットワーク切り替え後の動作も確認します。接続を切っても自動で再接続される場合は、まず条件が引き続き満たされていないか確認してください。テストのために一時停止する場合は、関連する自動接続を無効にしてから手動で切断します。Homeのスイッチを何度も操作するだけでは、自動条件と干渉して、切断操作が反映されていないように見えることがあります。
自動接続も、有効なサーバーと利用可能なネットワークが必要です。デバイスのスリープ解除、ネットワーク切り替え、Webログインが必要なWi-Fiなどでは、システムの状態と実際のアクセスに時間差が生じる場合があります。まずネットワークへのログインを済ませてから接続を確認してください。条件の範囲が広すぎると、不要なネットワークでも接続が続くことがあります。まず最小限の条件から始め、動作を確認してから範囲を広げましょう。すべての状況を一度に対象にしないでください。
問題を確認してからDNSを変更
DNSはドメイン名をアドレスに変換する、接続経路の一部です。ドメイン名では開けないが特定のアドレスには到達できる場合、名前解決の問題が考えられます。ただし、証明書、仮想ホスト、サービスへのアクセス方法も影響するため、この比較だけでは断定できません。エラー、名前解決の結果、ルーティングモードをあわせて確認し、Webサイトへのアクセス失敗をすべてDNSの問題と決めつけないでください。DNS設定を変えて偶然アクセスできた場合も、ほかの確認を省略しないようにしましょう。
変更前に、現在のDNS設定の入手元と元の値を記録してください。選択中のConfigに含まれる場合は、設定ファイルを複製してから編集します。アプリ画面から変更する場合は、対象の画面と項目を記録してください。調査対象の項目だけを変更し、保存後に接続を再確立して新しいリクエストを送信します。以前の接続やキャッシュが古い結果を使い続ける場合があります。比較テストでは、読み込み済みのページだけでなく、新しいセッションを確認してください。
DNSのアドレスとプロキシサーバーのアドレスを入れ替えないでください。前者は名前解決に、後者はプロキシ接続の確立に使われ、役割が異なります。ドメインルール、IPルール、名前解決の動作にも関連があり、ルールで名前解決が必要かどうかは種類とパラメータによります。no-resolveが表示された場合は、該当するルールの範囲を確認してください。1つのルールのパラメータをアプリ全体の通信処理方法として解釈しないでください。
プロトコル、TLS、テスト設定
TLS関連の設定はサーバー情報に合わせ、検証名、通信要件、デバイスの時刻を重点的に確認してください。設定情報の修正を、検証要件の緩和で代用しないでください。UDPを使うプロトコルや機能では、現在のネットワークとサーバーの両方が該当する通信をサポートしているか確認します。特定のネットワークで使えない場合は、ネットワークを比較してからプロトコルの条件を確認してください。あらゆる失敗を、クライアントに「高度なオプション」が必要な問題と考えないでください。
遅延テストの方法を変更する場合は、現在の設定項目の説明を読み、同じ方法で結果を比較してください。テスト対象自体に到達できるかどうかも数値に影響します。そのため、特定の方法で失敗しても、すべての通信が失敗するとは限りません。逆に、テストに成功しても、ほかの宛先や長時間の通信が正常とは限りません。Hysteria2の通信上の特性については、Hysteria2プロトコルの解説をご覧ください。
詳細な診断ログを有効にする前に、記録にドメイン、アドレス、接続情報が含まれる可能性を考慮してください。トラブルシューティングが終わったら、必要に応じて通常の記録レベルに戻し、必要以上のデータを残さないようにします。エラーを共有する場合は、関連部分だけを抜き出して個人情報を削除してください。サブスクリプションや認証情報を含む設定全体を送信しないでください。相手が必要とするのは障害の経路を理解する情報であり、接続を許可する情報ではありません。
この段階の完了条件は、設定をたくさん有効にすることではありません。各変更の目的、確認方法、元に戻す手順を説明できることです。設定を変更しても改善しない場合は元の値に戻し、次の項目を確認してください。どの変更がまだ有効か分からなくなった場合は、最後に利用できた設定のコピーに戻し、安定した基準を作ってから本章の順に確認します。一時的な変更を重ね続けないでください。
段階 08 / 復元できる状態を保つ
更新、バックアップ、日常のメンテナンス
日常のメンテナンスでは、現在何を使っているか、情報の入手元はどこか、問題が起きたときにどうすれば復旧できるかを把握します。サーバーサブスクリプション、Config設定、クライアントの更新はそれぞれ別の手順です。サブスクリプションは接続情報を更新し、設定はルーティングや関連項目を更新し、アプリはApp Storeから更新します。どれか1つが成功しても、ほかも同時に変わるわけではありません。作業前に対象の段階を明確にし、すべてを一度にやり直さないようにしましょう。
3種類の更新を分けて行う
サブスクリプションを更新する前に、現在のグループの入手元と有効性を確認してください。更新後は、項目が置き換わっていないか、デフォルトサーバーが選択されたままか、プロトコル設定が変わっていないかを確認してから接続テストを行います。更新できない場合は、現在利用できる項目を残し、すぐにグループ全体を削除しないでください。サーバーには接続できるのにサブスクリプションだけ更新できない場合は、サブスクリプション内容を取得する経路に問題がある可能性があります。それぞれを分けて確認してください。
Configを更新する前に、現在利用できる設定のコピーを保存し、新しい内容の用途と入手元を確認してください。古い設定に独自のルールを追加している場合は、更新で変更される可能性があるため、該当部分を事前に比較します。保存後、現在選択されているファイルを確認し、重要な宛先への接続をテストしてください。ファイル名が似ているだけで同じ設定と判断しないでください。実際の動作を決めるのはルール、ポリシー、関連設定です。
クライアントの更新はApp Storeから行います。デバイスの自動更新設定、またはストアの更新画面を利用してください。更新後は、既存の情報が正常か確認してから、普段使う接続をテストします。動作が変わった場合は、現在の画面の説明とストアに記載された更新情報を確認してください。特定のバージョンで問題が解決した、または新たに発生したと印象だけで推測しないでください。本マニュアルでは具体的なバージョン番号や更新日の一覧を管理していません。
情報のバックアップとデバイスの移行
バックアップでは、サーバー、サブスクリプションURL、設定全体を区別してください。ルールの断片だけでは、通常、認証情報や接続パラメータすべてを復元できません。サブスクリプションURLだけでは、手動で追加した個別サーバーが含まれない場合もあります。アプリが現在提供しているエクスポートまたはバックアップ方法を使い、何が含まれるか確認してください。バックアップ後はファイルが開けることと内容がそろっていることを確認します。ただし、唯一利用できる設定を上書きして確認しないでください。
バックアップにはパスワード、UUID、サブスクリプションのパラメータ、その他の認証情報が含まれる場合があります。ご自身で管理できる保護された場所に保存してください。ファイル名に用途を記載する場合も、認証情報全体は含めないでください。デバイス間で移行する際は、信頼できる転送方法と保存先を使い、移行後に一時コピーを削除します。設定を添えて問い合わせる場合は、個人情報を削除したコピーを作成してください。元のバックアップはご自身の保存場所に置き、公開の添付ファイルにしないでください。
新しいiPhoneまたはiPadに移行する場合は、まずApp Storeからクライアントを復元し、次に情報を復元してから、デバイス上でVPNの許可を設定してください。購入履歴、アプリデータ、システム権限は別々のものであり、すべてが自動的に引き継がれるとは限りません。新しいデバイスで接続とルールの動作を確認するまで、古いデバイスはそのままにしておき、確認後に必要なデータを整理してください。互換性と購入対象はApp Storeの製品ページに記載された内容が基準です。復元については購入済みアプリの復元をご覧ください。
簡潔なトラブル記録を作成
メンテナンスの記録は複雑でなくても構いませんが、現在のサーバー名、プロトコル、ルーティングモード、設定名、ネットワーク環境、テスト結果を含めてください。実際の認証情報は記録しないでください。問題が発生したら、直近の変更がサブスクリプションの更新、ルールの編集、システム権限の変更、ネットワークの切り替えのどれだったかを振り返ります。変更点が分かれば、すべての項目を再入力するより、関連する段階を優先して確認する方が原因を見つけやすくなります。
確認する順序
1. 現在のネットワーク自体が利用できるか
2. デフォルトサーバーが選択されたままか
3. Global Routingが想定どおりか
4. 現在のConfigが想定したファイルか
5. Connectivity Testと実際のアクセス結果が一致するか
6. 最近の変更を元の状態に戻せるか
長期間使っていない項目を整理する場合も、デフォルト選択、ポリシー、設定から参照されていないか確認してください。古い設定を削除する前に復元可能なコピーを保存し、古いサブスクリプションを削除する前に新しい入手元を確認します。項目数より、名前を分かりやすくすることが重要です。用途に応じて日常用とテスト用の設定を区別し、夜間やネットワークが不安定なときに未検証のファイルを誤って選ばないようにしましょう。統計記録を整理する前に、必要な通信量の記録も保存してください。
複数の宛先で同時に問題が起きる場合は共通の経路を、1つの宛先だけで起きる場合はその宛先と関連ルールを先に確認します。ご自身のサービス提供元に問い合わせる際は、プロトコル、ネットワーク環境、個人情報を削除したエラーを伝えてください。App Storeの購入アカウント情報は送信しないでください。クライアントの購入に関する問題は入手ガイドに戻り、用語の意味は用語集、基本の操作手順ははじめにをご覧ください。問題に対応する章で確認し、異なる段階のトラブルを混同しないようにしましょう。
メンテナンスを終えたら、日常使用の設定に戻し、On Demandの条件、デフォルトサーバー、現在のConfigを確認してから、新しいリクエストでテストしてください。一時的なテスト用スイッチは元に戻し、継続して確認が必要な問題を記録し、直近の利用可能なコピーを保管します。8段階の手順は繰り返し利用できます。対象の確認、許可、インポート、ルーティングの選択、接続確認、通信量の観察、設定変更、保存の順に進め、再インストールを繰り返して段階的な確認の代わりにしないでください。