Shadowrocketの使い方・設定ガイド：ルールと接続診断 - Shadowrocket iOS ガイド

01 / APP STORE

正規入手と購入について

購入・インストールの前に、製品情報を確認しましょう。ShadowrocketはAppleプラットフォーム向けの有料クライアントで、入手先はApp Storeのみです。似た名前のアプリが表示されても、日本語の通称だけで判断しないでください。このサイトの正規入手と確認のページで、デベロッパ名、公式アイコン、アプリIDの3点を照合してから購入手続きを進めてください。

製品ページで確認する3つの項目

デベロッパはShadow Launch Technology Limited、製品ページのアプリIDは932747118です。アプリ名は検索の目印になりますが、それだけでは確認できません。検索結果の概要だけでなく、詳細ページのデベロッパ欄も確認してください。情報が一致しない場合は購入を中止し、正しい製品ページを開き直してください。

アイコンは、このサイトのヘッダーに掲載している公式アイコンと同じ、白地に青紫の輪郭のデザインです。アイコンは3項目の確認のうちの1つであり、デベロッパ名やアプリIDの確認に代わるものではありません。ストアのリンクを保存するときは、製品ページのURL全体を残してください。後日ブックマークから開く場合も、URLとページ内容を改めて確認し、似た製品を同じアプリと取り違えないようにしましょう。

購入前に製品ページの互換性と購入に関する説明を確認してください。本ガイドでは主にiPhoneとiPadでの操作を扱います。Mac、Apple TV、Apple Visionへの対応状況も同じApp Storeページで確認できます。システム要件と購入対象の範囲はApp Storeページの記載に従い、別のデバイスでのインストール結果から、使用中のデバイスでも必ず利用できると判断しないでください。

アプリの購入費用と接続設定を区別する

Shadowrocketは買い切り型です。米国ストアでは約2.99米ドルですが、実際の金額は購入時のApp Storeページで確認してください。ストアによって現地通貨で表示されます。アプリの購入費用は販売チャネルに支払うもので、サーバーの有効性、サブスクリプションの期限、接続に必要なパラメータは、ご自身が利用しているサービスに関する事項です。アプリを購入しただけでは、それらは決まりません。

アプリの買い切り購入は、接続サービスの契約とは別です。インストール後に利用できるサーバー項目が表示されなくても、購入に失敗したわけではなく、接続情報をまだ読み込んでいない状態です。まずサブスクリプションURLまたはサーバーのパラメータ一式を用意してから、第3章に進んでください。手元に情報がない場合は、画面やルールの説明を先に読み、アプリを何度も再インストールする必要はありません。

購入アカウントと設定データは分けて考えましょう。App Storeの購入履歴はアプリを入手できることの確認に使い、アプリ内のサーバーやルールは別のデータとして管理します。機種変更後にアプリを再入手できても、サブスクリプション、手動で追加した項目、ローカル設定がすべて復元されるとは限りません。購入の復元と設定の復元は、それぞれ別に確認してください。

インストール後に確認すること

ダウンロードが完了したら、デバイスのホーム画面からShadowrocketを開き、正常に起動することを確認してから接続に進みます。このガイドを初めて読む場合は、使用中のデバイス、ネットワーク、設定の入手元と取得方法をメモしておくと、後の確認に役立ちます。これらの情報をアップロードする必要はありません。問題が起きたときに、インストール、読み込み、接続のどの段階で発生したかを見分けるための記録です。

ストアでは購入済みと表示されるのに、使用中のデバイスで再び支払いを求められる場合は、App Storeで購入に使ったアカウントが元の購入履歴と一致するか確認し、購入済み項目も確認してください。デバイスのサインイン状態とストアの購入状態を同じものとして扱わないでください。支払い、利用可能な地域、購入履歴に関する問題は、App Storeに表示される案内に沿って対応してください。

アプリのアップデートもApp Storeから行います。アップデート前に重要な設定を保存し、アップデート後は、まず普段使う接続が引き続き利用できるか確認してください。プロトコル、ルール、DNSを一度に変更しないようにしましょう。ストアのアップデート情報は機能の変更点を確認するために使います。このガイドでは特定バージョンの画面位置を固定していません。項目の並びが異なる場合は、アプリ内に表示される現在の名称と説明を確認してください。

02 / PERMISSION

初回起動とVPN権限

初回起動時は、まず画面の構成を確認し、接続する準備ができた段階でシステムの許可を設定します。Shadowrocketで接続するには、デバイスでVPN構成の追加を許可する必要があります。この許可と、サーバーアカウントの有効性は別の確認事項です。許可ダイアログで承認しても、システムがアプリの接続を認めたことを示すだけで、リモートサーバー、ルール、DNSの動作が確認されたわけではありません。

Home、Config、Data、Settingsを確認する

Homeでは主にサーバー項目の確認、接続先の選択、接続の操作を行います。Configは現在のルール設定の管理、Dataは通信量やリクエストに関する情報の確認、Settingsは各種動作設定に使います。各画面の役割を把握し、他のデバイスとまったく同じ位置にボタンがあるとは考えないでください。画面の配置はデバイスのサイズやアプリの変更によって異なります。

接続前にHomeを開き、ご自身のサーバー項目があるか確認してください。リストが空の場合は、接続スイッチを何度も操作しないでください。スイッチを入れてもサーバー情報は追加されません。追加または読み込みの操作をしたら、保存した項目を開いて内容を再確認できることを確かめてからHomeに戻ります。この確認で、「情報が保存されていない」問題と「接続できない」問題を切り分けられます。

Configに設定名が表示されても、そのルールが有効になっているとは限りません。まず現在選択されている設定ファイルを確認し、次にGlobal Routingの状態を確認してください。サーバーの選択、設定ファイルの選択、ルーティングの状態は、それぞれ別の要素です。3つを理解しておくと、同じデバイスでもリクエストごとに異なる処理が行われる理由を判断できます。

システムの許可が意味すること

初めて接続をオンにすると、VPN構成の追加を許可し、デバイス認証で操作を確認するようシステムから求められることがあります。ダイアログの内容を読み、Shadowrocketで接続を開始した直後に表示されたことを確認してから、システムの手順に従ってください。これはデバイス側の設定変更であり、システム認証の画面にサーバーのパスワードを入力する必要はありません。サーバーの認証情報は、該当する接続項目にのみ入力してください。

以前にキャンセルした場合は、アプリに戻って接続を再度開始し、システムからもう一度許可を求められるか確認してください。ダイアログが表示されない、またはスイッチがすぐに元に戻る場合は、システム設定のVPN状態と関連する案内を確認します。管理対象のデバイスには追加の制限がある場合があります。管理ポリシーに関する明確な表示が出たときは、構成を何度も削除して試すのではなく、そのデバイスで該当する接続が許可されているか確認してください。

許可の後も、有効なサーバーを選び、現在のネットワークからサーバーのアドレスにアクセスできるか確認する必要があります。システムに表示される接続状態は、ローカルでの接続処理の一部です。Webページが読み込めるかどうかは、ルール、サーバー認証、名前解決、接続先サイトにも左右されます。そのため、「許可済み」「接続済み」「リクエスト成功」は別々の確認項目として記録してください。

設定をすべて消去せず、競合を解消する

デバイスにすでにVPN構成がある場合は、テスト時にどの構成が現在の接続を制御しているか確認してください。複数の関連スイッチを切り替えたまま結果を判断しないでください。まず現在の接続を停止し、システムの状態が想定どおりに戻ったことを確認してからShadowrocketを起動します。既存の構成名と用途は記録し、仕事、学校、デバイス管理に必要な項目を影響範囲が分からないまま削除しないでください。

初回の確認中はOn Demandをいったん無効にしてください。ネットワークの切り替えやドメインへのアクセスをきっかけに自動接続が動作すると、手動操作が反映されていないように見えることがあります。まず手動で接続と切断を一通り行い、基準となる状態を確認します。サーバーが使えることを確かめてから、自動接続の条件を1つずつ追加すれば、設定ごとの影響を把握しやすくなります。

iPhoneとiPadで権限設定の仕組みは同じですが、横向き表示、Split View、ウインドウ幅によって画面の配置が変わります。項目が見つからない場合は、幅の狭いSplit Viewを終了し、アプリを全画面で開いて英語の項目名を探してください。画面の位置が変わったからといって、サブスクリプションを再度読み込む必要はありません。表示レイアウトの変更だけでは、設定データが破損したとは判断できません。

システムからVPN構成を削除しても、アプリ内のサーバーが削除されるとは限りません。また、アプリを再インストールしても、すべての権限問題が解決するわけではありません。システムが構成の異常を明確に報告し、復元できるデータを保存している場合に限り、関連項目の再作成を検討してください。操作後は権限の確認と手動接続を最初から行い、削除前の状態を現在の結果の判断に使わないでください。

03 / SERVER & SUBSCRIBE

サーバーの追加と既存サブスクリプションの読み込み

読み込みを始める前に、手元の情報が何に当たるか確認してください。単一のサーバー情報は1つの接続先を示し、サブスクリプションURLは通常、複数のサーバー情報の取得や更新に使います。.confファイルは主にルールや関連する動作設定を含みます。これらは組み合わせて使えますが、サブスクリプションURLをサーバーのホスト名として扱ってはいけません。また、ルールファイルを読み込んだだけで有効なサーバーを利用できるとは限りません。

Add Server：プロトコルのパラメータを確認する

手動で追加する場合は、HomeからAdd Serverを開き、手元の情報に合ったプロトコルを選んでから、サーバーアドレス、ポート、認証情報を入力します。必要な項目はプロトコルによって異なります。どちらもパスワードを求めるという理由だけで、異なるプロトコルのパラメータを別のフォームに入力しないでください。保存する前に元の情報と1項目ずつ照合し、コピー時に空白や改行が混入していないか確認します。

サーバーアドレス欄には、提供されたホスト名またはIPアドレスを入力し、ポートは別の欄に入力します。Webページの完全なURLやパスをホスト欄に入れないでください。表示名は項目を見分けるためのメモであり、ホスト、ポート、認証の誤りを直すものではありません。後で接続先を切り替えたりDataを確認したりするときに間違えにくい、分かりやすい名前を付けましょう。

Shadowsocksでは通常、暗号化方式とパスワードを確認します。VMessやVLESSではUUIDと対応するトランスポート項目が関係することがあります。Trojanでは認証情報とTLSの設定を元の情報に沿って入力してください。Hysteria2とWireGuardはそれぞれパラメータの構成が異なります。提供されていない項目を名前から推測したり、1つのプロトコルの入力方法をすべての接続タイプに当てはめたりしないでください。

プロトコル	確認する項目	よくある間違い
Shadowsocks	サーバー、ポート、暗号化方式、パスワード	元の情報と暗号化方式が異なる
VMess / VLESS	UUID、トランスポート方式、関連項目	トランスポートパスやHostをホスト欄に入力する
Trojan / Hysteria2	認証情報、TLS、サーバー名	証明書の検証に必要なサーバー名を見落とす
WireGuard	鍵、アドレス、Endpoint、関連パラメータ	鍵と通常のパスワードを混同する

SubscribeとScan QR Code

既存のサブスクリプションは、アプリの読み込み機能から追加できます。画面の案内に従ってSubscribeまたは該当する種類を選び、ご自身のサービス提供元から取得したURLを入力してください。サブスクリプションURLには個人を特定できる情報が含まれる場合があるため、パスワードと同様に管理しましょう。読み込み後は、追加された項目の名前、件数の変化、プロトコルを確認してください。項目が一括で表示されたからといって、すべての接続が有効だとは限りません。

サブスクリプションの更新に失敗した場合は、URLの形式が誤っているのか、取得処理に失敗したのかを切り分けます。コピーが完全か、引用符や改行が含まれていないか確認し、サブスクリプション自体がまだ有効かも確かめてください。取得段階のエラーは、サーバーへの接続テストに進む前に起きている可能性があります。その場合、サーバーのパスワードを何度も変更しても解決にはつながりません。更新時の表示を確認し、URLへのアクセス条件を見直してください。

Scan QR Codeは、すでに持っている接続情報を読み込むときに便利ですが、スキャンは入力方法の1つにすぎず、情報の信頼性を追加で検証するものではありません。読み取る前にQRコードの提供元を確認し、読み取り後は生成された項目のプロトコル、アドレス、重要なパラメータを確認してから保存してください。カメラや写真へのアクセス許可は、その操作に必要な範囲で設定すれば十分です。項目を1つ読み込むために、関係のないデータへのアクセスを許可する必要はありません。

サブスクリプションの更新とConfigの違い

サブスクリプション内の項目は、更新時に置き換え、削除、または名前変更される可能性があります。そのため、自動管理される項目を、長期保存する手動メモの置き場所として使うのは避けてください。編集したテスト用項目を残す必要がある場合は、独立したコピーとして保存できるか確認し、入手元も記録します。バックアップなしで普段使うサブスクリプションを上書きすると、更新後に手動変更とサーバー側の変更を区別できなくなるおそれがあります。

Config内のファイルは、個別に選択状態と、ルールが参照するポリシーの有無を確認してください。ファイルを読み込めたことが分かるのは、内容が受け付けられたということだけです。各ルールが利用環境に合っているとは限りません。内容をよく知らない設定は、まずGeneralとRuleを読み、意図しない処理方針がないか確認してから有効にしてください。複雑な箇所が理解できない場合は、ひとまず変更せず、該当する説明を参照しましょう。

読み込み後は、項目を1つ選んで接続を確認してから、グループ分けや更新頻度を整理してください。入力ミスと一括管理の問題を切り分けやすくなります。プロトコルの項目については対応プロトコルとパラメータの概要、設定ファイルの構成については.confの各セクションの説明をご覧ください。確認の代わりに何度も読み込みを繰り返さないでください。

04 / GLOBAL ROUTING

Global Routingの3つのモードとルールの順序

Global Routingでは、全体の通信をどのように処理するかを選びます。Configは設定に従うモード、Proxyはプロキシ経由、Directは直接接続です。画面で操作するときは、これらの英語表記を確認してください。3つのモードはサーバーのプロトコルでも、速度の段階でもありません。全体の接続を調べるのか、特定のルールを調べるのかを先に決めると、条件を取り違えずに結果を判断できます。

Config、Proxy、Directで確認できること

Configでは、現在選択している設定に基づいてリクエストの処理先を決めます。日常的なルーティングに適していますが、設定内のルール、ポリシー、参照先のサーバーがすべて正しく機能している必要があります。Configで特定の宛先にアクセスできない場合は、すぐにサーバーが使えないと判断せず、実際に一致したルールを確認してください。宛先がDirectに振り分けられている、またはREJECTに指定されている可能性があります。

Proxyは通信をプロキシ経由で処理します。ルールの影響を減らして確認するためのテスト条件として使えますが、有効なサーバー、正しい認証情報、利用可能なネットワークが必要です。DNS、リモートサーバーへの到達性、接続先自体の障害は解決できません。テストではこの項目だけを変更し、同じ宛先で結果が変わるか確認してください。サーバーも同時に切り替えると、ルーティングモードの影響だけを比較できなくなります。

Directは通信を直接接続で処理するモードであり、アプリの接続を切るという意味ではありません。直接接続を試すときも、システムの接続状態とアプリの設定を確認してください。Directで特定の宛先にアクセスできても、現在のネットワークからその宛先に接続できたことしか分かりません。他のドメイン、ポート、プロキシサーバーにも接続できるとは限らず、ルール全体の評価にも使えません。

画面上のモード	主な判断基準	確認に適した項目
Config	現在の設定とルール	ルールの適用順と処理先
Proxy	現在選択中のプロキシ	ルールの影響を抑えたプロキシ接続
Direct	現在のネットワークでの直接接続条件	宛先に直接接続した場合の基準

Rule：具体的な条件からFINALまで

ルールは順番に確認します。まずドメインやネットワーク範囲など具体的な条件を見て、その後に広い条件を確認し、最後にFINALを確認してください。先にあるルールで処理方法が決まると、後続の似たルールは通常そのリクエストの結果を変えません。新しいルールを追加する前に既存項目を検索し、例外ルールが広い条件の後ろに置かれていないか確認してください。ルールが存在していても、実際には一度も適用されないことがあります。

DOMAINは完全一致のドメイン、DOMAIN-SUFFIXはドメインのサフィックス、DOMAIN-KEYWORDはドメイン内のキーワードに基づいて照合します。それぞれ一致する範囲が異なります。特にキーワードは、想定外のドメインにも一致する可能性があるため慎重に使ってください。ルールに記述するドメインには通常、Webページのパスは含めません。ページの完全なURLをそのまま貼り付けないでください。

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

この例はRuleの構造を示すもので、すべてのデバイスですぐに有効化できる設定一式ではありません。先頭のドメインルールが、その後のネットワーク範囲や地域に関する条件より先に処理を決める場合があります。ローカルネットワークの範囲は、IP-CIDRの記述方法を示しています。PROXY、DIRECT、REJECTはポリシーのキーワードです。一方、画面上のProxyとDirectは大文字・小文字が異なるため、フィールド名と混同しないでください。

ドメインルールとアドレスルールの違い

IP-CIDRとIP-CIDR6はそれぞれ対応するアドレス範囲を対象とし、GEOIPはアドレス分類データに基づいて判断します。これらはドメインルールとは異なる情報を使います。アドレスに関する条件を適用するには、まず接続先のアドレスが分かっている必要があります。1つのドメインが複数のアドレスに解決されたり、ネットワーク環境によって解決結果が変わったりすると、実際に一致するルールも変わることがあります。確認時はドメインとアドレスの両方を記録してください。

FINALは、それ以前のルールに一致しなかった通信を処理するため、ルールの末尾に置きます。FINALを前方に移動すると、後続のルールが想定どおりに機能しなくなります。例外を追加する場合は、まずどの既存ルールより優先させる必要があるか確認し、適切な位置に配置してください。「優先させる」ためだけにすべての新規項目を先頭に集めると、ルール間の関係が分かりにくくなり、後の管理が難しくなります。

変更後は具体的な宛先で確認し、ページが開くかだけでなくDataで適用されたポリシーも確認してください。ページは複数のドメインを利用することがあり、メインの文書が読み込めても、画像、ログイン、APIリクエストが同じ経路を通るとは限りません。キーワードは用語クイックリファレンスで確認できます。ルールの確認が終わったら普段使うモードに戻し、一時的なテスト状態をそのままにしないでください。

05 / CONNECTIVITY

接続、遅延テスト、結果の確認

接続確認はローカルネットワークから始め、サーバー、プロトコル、ルール、接続先へのアクセスを順に確認します。遅延テストで数値が返っても、その時点でテスト方法に応答があったことを示すだけで、実際のサービスへのリクエスト全体を確認したことにはなりません。比較するときは、サーバー、Global Routingのモード、テスト対象をそれぞれ1つに決めてから実施し、複数の変更を重ねて結果が分かりにくくならないようにしてください。

再現できるテストの基準を作る

まず現在のWi-Fiまたはモバイル通信が利用できることを確認します。ログインページへの対応が必要なネットワークや、一時的な制限がある場合は、Shadowrocketを切断した状態で先に対処してください。ネットワークの基本的な通信が確立していない状態では、サーバーのプロトコルを変更しても意味がありません。接続前にネットワークの種類を記録し、テスト中にネットワークを切り替えた場合は、以前とは別の条件として確認してください。

Homeで、テストするサーバー項目が選択されていることを確認し、サブスクリプションがまだ有効か、最近の更新で認証情報が変更されていないかも確認してください。次にGlobal Routingと現在の設定を確認します。名前が似ているサーバーは、詳細を開いてアドレスを確かめるほうが確実です。読み込みや更新で項目の並びが変わることがあるため、リスト上の位置だけで選択状態を判断しないでください。

接続を開始したら、アプリの表示とシステムの状態を確認してから、新しいリクエストを送信します。ブラウザに表示されているページがキャッシュの場合もあり、画面がそのまま表示されているだけでは新しいリクエストの成功を確認できません。決めておいた宛先を再読み込みし、Dataで該当時刻の記録を探して、操作時刻、リクエスト結果、実際の処理ポリシーを対応付けます。この手順を同じ条件で繰り返せるようにしてください。

Connectivity Testと実際のアクセスを区別する

Connectivity Testは、テスト方法や対象の設定によって結果が変わります。方法の異なる遅延値をそのまま並べて比較しないでください。接続の確立を中心に確認する方法もあれば、リクエストと応答まで含めて確認する方法もあります。使用中の方法を確認し、結果が安定しているかを見てください。1回の数値が小さいからといって、すべてのWebページやアプリでのアクセスが速くなるとは限りません。

テストがタイムアウトした場合も、実際のリクエストと合わせて判断してください。サーバーが特定のプローブに応答しなくても、必要な通信は処理できる場合があります。反対に、プローブへの応答があっても、認証や転送の段階で失敗することがあります。結果が一致しないときは、テスト方法の名称とエラー情報を記録し、同じサーバーで実際にアクセスして確認してください。リストの結果だけを見て、すべての項目を削除しないでください。

すべての項目が同時に失敗する場合は、現在のネットワーク、サブスクリプションの有効性、テスト対象、設定変更など、共通する条件を先に確認します。1つの項目だけ失敗する場合は、その項目のプロトコル、アドレス、ポート、認証情報を確認してください。共通の失敗と個別の失敗では、調べる範囲が異なります。根拠なく暗号化方式やDNSを変更するより、対象範囲を絞って確認しましょう。

症状	最初に確認する項目	次に行うこと
接続スイッチがすぐに戻る	許可、システムの表示、選択中の項目	権限とローカル設定を再確認する
接続済みだが宛先にアクセスできない	Dataのドメイン、ルール、エラー	DNSとポリシーを分けて確認する
ページの一部のリソースだけ読み込めない	関連するドメインと適用ルール	サイト全体で判断せず、リソースごとに確認する
ネットワーク切り替え後に失敗する	現在のネットワークと以前の接続状態	再接続して新しい基準を作る

エラーが発生した段階から原因を絞り込む

ドメインの名前解決に失敗した場合は、まずDNSの経路を確認します。接続がタイムアウトする場合は、サーバーに到達できるか確認してください。認証エラーでは認証情報を、証明書関連のエラーではサーバー名、デバイスの時刻、元のTLSパラメータを確認します。エラーメッセージは発生段階によって異なるため、「ネットワーク不調」とひとまとめにせず、表示された文面を記録してください。サーバー名の不一致を隠すために証明書の検証を無効にしないでください。

Proxyでは利用できるのにConfigでは失敗する場合は、ルールの適用と参照先のポリシーを重点的に確認します。どちらのモードでも失敗する場合は、共通するサーバーと名前解決の条件を確認してください。この比較は原因を絞り込む手がかりになりますが、それだけで原因が確定するわけではありません。テスト前後で同じ宛先、ネットワーク、サーバーを使って初めて、結果の違いを判断できます。

接続できても速度が安定しない場合は、ネットワークの切り替え、接続先の応答、サーバーの状態、通信を続けたときの状況を分けて確認します。大容量ファイル、リアルタイム通信、短時間のWebページでは挙動が異なるため、1つの用途だけで判断しないでください。まずよく起きる失敗を再現し、一度に1項目だけ変更してテストします。結果を記録してから、次の調整に進んでください。

確認が終わったら、いったん手動で切断して再接続し、同じ結果を再現できるか確かめます。最初の成功が以前のセッションによるものだった場合、再接続で問題が明らかになることがあります。再接続が安定したら、On Demandなどの自動動作を段階的に戻してください。操作手順を手早く確認する場合は使い方に戻り、この章では各項目を個別に確認する理由を参照してください。

06 / DATA

Dataで通信量とリクエストを確認する

Dataでは、現在の接続を通過した通信やリクエストの手がかりを確認できます。累計値をそのままサービスの請求・使用量と同一視しないでください。アプリ、システム、ご利用中のサービスでは、集計範囲や期間が異なる場合があります。確認を始める前に、特定のリクエストの経路を知りたいのか、失敗した段階を見つけたいのか、操作前後の通信量を比較したいのかを明確にしてください。

操作と記録を対応付ける

確認前に時刻、ネットワーク、サーバー、Global Routingを記録し、決めたページを再読み込みするなど、再現可能な操作を1つだけ行います。その後Dataを開き、その時刻の前後に追加された記録を確認してください。複数のアプリを同時に開いてから対応関係を推測しないでください。バックグラウンド同期による通信もあるため、時刻が近いことだけで判断せず、ドメインや接続先のアドレスも確認しましょう。

1つのページには、メインの文書、画像、API、その他のリソースへのリクエストが含まれることがあるため、複数のドメインが記録されても不自然ではありません。まず、失敗した機能に直接関係するリクエストを探します。ページが表示されない場合はメインの文書、ログインに失敗する場合は認証API、画像が表示されない場合はリソースのドメインを確認してください。ページのURLだけで検索してサイト全体の状態を判断するより、リクエストを個別に確認するほうが正確です。

記録に表示される項目は現在の画面に従って確認し、接続先、処理ポリシー、適用ルール、接続状態、エラーを重点的に見ます。リクエストによって表示される情報は異なることがあります。項目が1つ空だからといって、アプリが処理していないとは限りません。必要に応じてリクエストを新たに発生させ、現在の接続と設定が有効になった後の記録であることを確認してください。古いセッションの記録を使わないようにしましょう。

ルールの結果から設定をたどる

リクエストが実際にDIRECTで処理されている場合は、どのルールが決定したかを調べ、それが想定どおりか確認してください。PROXYの場合は、最終的にどのサーバーまたはポリシーが使われたかを確認します。REJECTが表示された場合は、サーバーのパスワードを変更するのではなく、拒否を決めた条件を確認してください。拒否ポリシーはリモートサーバーに接続する前にリクエストの結果を決めることがあります。

ドメイン情報とIPアドレスは合わせて確認してください。1つのドメインが複数のアドレスに解決されることがあり、同じアドレスで複数のサービスが提供される場合もあります。アドレスだけからアクセスの意味をすべて特定することはできません。接続記録にドメイン照合に使える情報が含まれないこともあります。その場合は、当時表示されていた情報の範囲を保ち、後から調べたドメインが元のリクエストにも含まれていたと決めつけないでください。

ルールを変更した後は、新しい接続で結果を確認してください。既存の接続では、確立時の処理経路が引き続き使われることがあります。そのため、「設定を変更したのに古い記録が変わらない」からといって、保存に失敗したとは限りません。該当するリクエストを停止し、必要であれば再接続して同じ操作を繰り返します。新旧の記録で適用ルールを比べると、変更が後続の処理に反映されたか判断できます。

累計通信量とデータの保護

通信量を確認する前に、現在の接続、特定の期間、アプリが保持する累計値など、表示範囲と集計開始条件を確認してください。詳細は画面の説明に従います。集計期間がそろっていない場合、2つの数値をそのまま比較しても判断できません。再接続、記録の削除、表示フィルターの変更によって確認範囲が変わることもあるため、比較前に条件を記録しておきましょう。

アップロードとダウンロードはデータの転送方向を示すもので、利用者が実際に内容を見たかどうかを表すものではありません。バックグラウンド更新、自動バックアップ、ページの先読み、再試行でも通信が発生します。通信量が予想以上に増えた場合は、短い時間帯と単一のアプリに範囲を絞り、他の目立った通信を止めて変化を確認してください。累計値が増えたことだけを理由に、特定のサーバー項目に問題があると判断しないでください。

サービス側の集計とローカルの表示が異なる理由には、プロトコルのオーバーヘッド、集計期間や範囲、他のデバイスでの利用などがあります。それぞれの説明を確認し、すべてのバイト数を一致させようとしないでください。ローカルのDataは接続の動きを調べる補助に適していますが、残りの利用量、有効期限、集計ルールに関するご利用中のサービスの説明に代わるものではありません。

リクエスト記録には、アクセスしたドメインやアドレス、時刻、個人の行動に関する情報が含まれることがあります。書き出しやスクリーンショットの前に、問題に関係する部分だけを選び、サブスクリプションURL、認証情報、無関係なアクセス内容を隠してください。記録を消去する前に、再現に必要なエラー文を保存します。消去後に過去の問題を調べるのは難しくなるため、診断が終わってから整理してください。

Dataの記録とブラウザの表示が一致しない場合は、まずキャッシュ、古い接続、対象リクエストの特定が正しいかを確認してから、調査範囲を広げます。システム上の他の動作によって観察にずれが生じることもあり、すべての記録を前面のページに関係するものと決めつけないでください。操作を固定し、短い時間で確認し、同じテストを繰り返して対応関係をつかむことが、Dataを読み解く基本です。

07 / SETTINGS

Settings、DNS、On Demand

Settingsは、接続が安定してから項目ごとに調整してください。設定が名前解決、接続のトリガー、接続動作のどれに影響するかを明確にし、変更前の値と変更理由を記録します。画面の項目はデバイスやアプリの変更によって異なるため、名称と利用できる範囲は実際の表示に従ってください。すべての機能を有効にする必要はなく、複雑な設定を接続成功の条件と考える必要もありません。

DNS：名前解決の経路を確認する

DNSはドメイン名をアドレスに解決し、ルールによるルーティングはリクエストの処理方法を決めます。両者は関係しますが、同じものではありません。名前解決に失敗すると、ブラウザは通常の接続段階に進めないことがあります。その場合、プロキシサーバーだけを切り替えても解決しない可能性があります。まずDNSの設定がアプリ、現在の設定、ネットワーク環境のどこから適用されているか確認し、変更箇所を決めてください。

ConfigのGeneralとSettings内の関連項目が、実際の動作に共同で影響することがあります。適用の優先順位は、現在のアプリの説明で確認してください。複数の場所に異なる値を入力し、そのうち1つだけを覚えている状態は避けましょう。変更前に元の設定を記録し、設定のコピーも保存します。テストでは設定元を1つだけ変更し、新しいリクエストの名前解決とアクセス結果を確認してから変更を維持してください。

DNSサーバーは数が多ければよいというものではありません。異なるDNSの経路で別のアドレスが返る場合や、現在のネットワークまたはプロキシ経由でないと接続できない場合があります。まず使用中のDNSサービスに現在の条件でアクセスできるか確認し、対象のリクエストに適しているか判断してください。DNSを何度も変更しても、誤ったパスワード、サーバーポート、拒否ルールは修正できません。

ドメインの結果がキャッシュされるため、変更後もしばらく古いアドレスが表示されることがあります。それだけで設定が無効とは限りません。新しいリクエストを発生させ、関連する接続を再確立して、実際の名前解決の手がかりを確認してください。WebサイトへIPアドレスで直接アクセスしても同じテストにはなりません。TLSのサーバー名やサイトのルーティングにドメインが必要な場合があります。テスト方法を変えるときは、その方法で確認できる条件の範囲を明確にしてください。

On Demand：手動接続から自動接続へ

On Demandは、条件に応じて接続関連の動作を開始する機能です。手動接続が安定してから設定してください。どのネットワーク条件で接続し、どの条件では接続しないのかを明確にしてから、ルールを1つずつ追加します。最初からすべてのWi-Fi、モバイル通信、ドメイン条件を対象にすると、自動動作と手動スイッチの影響が重なり、どの条件が機能したのか判断しにくくなります。

Wi-Fi名を条件にする場合は、実際のネットワーク名を確認し、似た名前のネットワーク、ゲストネットワーク、デバイスによる自動切り替えにも注意してください。ネットワーク名の一致は接続を開始する条件を示すだけで、そのネットワークで同じようにアクセスできることを保証しません。テストでは他の条件を変えず、対象ネットワークに切り替えた後、状態が変わるまで待ちます。アプリとシステムの状態を確認し、実際の結果を記録してください。

モバイル通信やドメインを条件にする場合も、トリガーが動作するタイミングとルールの順序を確認してください。リクエストが発生したか、ドメインが条件に一致したか、システムが接続を許可しているかによって結果が変わります。自動接続はサーバーの稼働を保証する機能ではありません。リモートサーバーに到達できなければ、トリガーが動作してもアクセスは完了しない場合があります。「条件に一致したか」と「サービスを利用できたか」は分けて記録してください。

On Demandをオフにした後も、現在の接続が維持されているか、システムの状態が想定どおりか確認してください。自動接続ルールを無効にする操作と、既存セッションを終了する操作は別です。スイッチの状態だけを見て、すべての接続が切れたと思い込まないでください。条件の整理方法はOn Demandの接続条件設定をご覧ください。

その他の動作設定で気をつけること

ローカルネットワークにアクセスできない場合は、まず接続先がローカルのネットワーク範囲に属するか、現在のルールでどう処理されるか確認し、その後で関連設定を確認します。家庭内のデバイス、プリントサービス、管理ページでは、ローカルデバイスの検出が必要な場合があります。すべての通信に同じポリシーを適用しないでください。ネットワーク関連の項目を変更した後は、明確なローカルの接続先でテストし、公共のWebページにアクセスできたことをローカル接続の確認に代用しないでください。

IPv6に関する問題では、まず現在のネットワークと接続先が実際に使用しているアドレスの種類を確認し、次にIP-CIDR6などのルール範囲を調べてください。アドレスの機能を単に無効にしても、症状が変わるだけで原因が分かるとは限りません。元の値を記録し、同じ宛先を異なる条件で比較して、変化が問題に関係していると確認してから、設定を恒久的に変更するか決めましょう。

基本的な接続を行うためだけに、書き換えや証明書関連の機能をまとめて有効にしないでください。それぞれ用途と影響範囲が異なるため、内容を理解し、必要な許可を得たうえで対象を限定する必要があります。サーバーの通常の読み込み、Global Routing、接続確認は、まず簡潔な設定で行えます。追加機能が問題に関係していない場合は、変更せずにおくほうが診断しやすくなります。

08 / MAINTENANCE

日常の管理、機種変更、問題解決の確認

日常の管理では、設定を頻繁にリセットするのではなく、内容を理解し、復元できる状態に保つことが大切です。アプリの購入記録、手元のサブスクリプション情報、サーバー項目、現在の設定、個人による変更を分けて保存しておけば、問題が起きたときに必要な箇所だけを確認できます。整理後はもう一度接続を確認し、普段使うサーバー、Global Routing、ルールの処理先が変わっていないことを確かめてください。

アップデート前後の基準を残す

アプリのアップデートはApp Storeから行い、サブスクリプションの更新では、すでに利用しているサブスクリプションからサーバー情報を取得します。診断記録で両方を単に「更新」と呼ばないでください。アプリのアップデート、サブスクリプションの更新、ルールの変更を同時に行うと、問題の原因を特定しにくくなります。できるだけ別々に操作し、各操作の後に決めた宛先への接続を確認して、安定したことを確かめてから次に進みます。

サブスクリプションを更新する前に、残しておきたい独立した項目とメモを保存し、現在使っているサーバーが項目の置き換えによって影響を受けないか確認してください。更新後は、項目名の変化、選択状態、接続結果を確認します。更新完了の表示だけで判断しないでください。新しい項目に接続できず、独立して保存した元の項目が使える場合は、アプリ全体を消去するのではなく、プロトコルの項目やサーバー側の変更を比較してください。

設定ファイルを変更するときは、動作確認済みのコピーを保存し、日常用とテスト用を区別できる名前にしてください。唯一の利用可能な設定を一時的な実験用にしないでください。複雑な変更は、ドメインルール、ネットワーク範囲のルール、Generalの設定などの段階に分け、各段階で1つずつ確認します。こうすれば、すべてを作り直さずに、問題のある変更だけ元に戻せます。

機種変更後は3つの層を個別に確認する

第1段階はアプリの入手資格です。新しいデバイスのApp Storeで元の購入アカウントを使用し、購入済み項目を確認してください。システム要件と購入対象の範囲はApp Storeページの記載に従います。アプリを再ダウンロードできた時点で完了するのは、アプリの復元だけです。続けてアプリを開き、ローカルに保存された情報を確認してください。ストアで購入済みと表示されても、サーバー設定が移行された証明にはなりません。

第2段階はサーバーとサブスクリプションの情報です。ご自身で保存したURLやパラメータを使って復元し、現在も有効か改めて確認してください。以前のデバイスで使えていたサブスクリプションも、現在有効とは限りません。手動で追加した項目は、コピー時にパラメータが欠けていると接続できない場合があります。復元後は、まず普段使う項目を1つ選んでテストし、まとめて整理する前に接続を確認します。接続できるまでは、自動接続の条件を追加しないでください。

第3段階は、現在の設定と個人用の設定です。ルールファイルを復元したら、選択状態、Global Routing、DNS、On Demandを確認し、初回接続時のシステム許可も確認してください。以前のデバイスで行った許可は、新しいデバイスでの確認に代わるものではありません。iPadでの購入復元や画面配置については、iPadでの購入済みアプリの復元と使い方をご覧ください。

移行用の設定には、サーバーアドレス、サブスクリプションの認証情報、その他の個人情報が含まれる場合があります。ご自身で管理できる保護された場所に保存してください。書き出した後は、ファイルの内容と復元方法を確認します。バックアップを試すために、唯一の利用可能なコピーをすぐに削除しないでください。移行を完了して接続を確認した後、必要に応じて使わなくなった一時コピーを整理してください。

必要最小限の記録で問題を解決する

トラブルの記録には、少なくとも発生時刻、デバイスの種類、現在のネットワーク、サーバーのプロトコル、Global Routing、使用中の設定、エラーの原文を含めてください。直近の成功時の条件と、最近変更した項目も加えれば、問題の範囲を絞り込めます。記録にはパスワード、鍵、サブスクリプションURL全体、個人のアクセス内容を含めず、問題の把握に必要な構成だけを残してください。

問題が起きたら、まず再現してから段階を切り分けます。アプリを開けるか、権限の設定が完了しているか、情報を読み込めているか、サーバーに到達できるか、ルールが正しいか、接続先が正常かを確認してください。各段階で確認する内容を分け、あらゆる問題を再インストールで解決しようとしないでください。ローカルデータまたはインストール状態に原因があると確認できた場合に限り、該当する復元方法を検討し、先に必要な情報を保存します。

修正後は、反対方向からも確認します。普段使うモードに戻し、再接続して、元の失敗操作を繰り返します。その後Dataで適用されたルールとポリシーが想定どおりか確認してください。一時的なテストモードでしか成功していない場合、問題はまだ解決していません。安定したことを確認してから診断記録を整理し、最終的に変更した内容を記録しておけば、同じ問題が起きたときに比較できます。

長期的な管理では、用途を説明できない設定を増やすのではなく、不要になった重複テスト項目を削除してください。用途が明確な基準を少数残し、サブスクリプションの有効性と購入記録から復元できることを定期的に確認すれば十分です。日常の操作はクイック使い方ガイド、用語の確認は用語クイックリファレンスをご覧ください。購入やインストールに関する問題は、正規入手ページの購入済みアプリの復元方法を確認してください。