3つを分けて考える：アカウント、サブスクリプションリンク、クライアント
つながらない、頻繁に切断される、サブスクリプションが無効だと表示される——初心者がこうした状況に直面したとき、まず疑うのは「回線が壊れた」ではないでしょうか。しかし実際には、アカウント・サブスクリプションリンク・クライアントという3つのうち、どれか一つに問題が起きているケースのほうが多く見られます。この初心者向けセキュリティガイドでは、設定の切り替え方ではなく、まずこの3者の境界をはっきりさせます。誰がログイン権限を持ち、誰が接続権限を持ち、それぞれを失ったときはどの順序で対処すべきなのか。
| 項目 | 何を指すか | 管理を離れたときの影響 | 対処方法 |
|---|---|---|---|
| アカウント（ユーザー名 + パスワード） | ユーザーパネルにログインするための認証情報 | 第三者に注文情報を見られ、サブスクリプションリンクをリセットされる | パスワードを変更する。他のサイトと使い回している場合は、そちらも併せて変更する |
| サブスクリプションリンク | クライアントにインポートすると、回線設定を自動で取得するURL | アカウントなしでインポートし、回線を利用できてしまう | パネルでサブスクリプションをリセットすると、古いリンクは即座に無効になる |
| クライアント設定 | 端末内に保存されたノード情報とルーティングルール | 同じ端末を使う他のユーザーが読み取れる | 設定を削除し、ログアウトし、エクスポートしたファイルを消す |
3行のうち、最も過小評価されがちなのが2行目です。アカウントには少なくともパスワードという壁がありますが、サブスクリプションリンクはそれ自体が認証情報です。リンクを手に入れた人は、あなたのユーザー名を知る必要も、あなたの同意を得る必要もなく、インポートするだけで同じ回線群に接続できてしまいます。
ある情報を送るべきかどうかは、ただ一点で判断できます。それが接続の確立に使えるかどうかです。使えるならパスワードと同じ扱いにし、使えないなら普通の情報とみなしてよいでしょう。
なぜサブスクリプションリンクはアカウントの認証情報と同等なのか
サブスクリプションリンクは通常 http または https で始まり、一見するとただのURLにしか見えません。しかし開くと、エンコードされたテキストが返され、クライアントがそれをデコードすると、サーバーアドレス、ポート、プロトコル種別、暗号化方式、そしてパスワードまたは UUID といった接続パラメータがすべて得られます。つまり「どのサーバーに、どの資格情報で接続するか」という情報は、すでにリンクの中に書き込まれているのです。
以下2行は形式を示すためのサンプルです。アドレスはドキュメント用の予約済み網域 203.0.113.0/24 から取り、パスワードはデモ用の値であり、実際に接続できるサーバーを指すものではありません。
ss://[email protected]:8388#サンプルノード
trojan://[email protected]:443?sni=example.com#サンプルノードプロトコルによって認証情報の形は異なりますが、共通しているのは、リンクの中に接続を直接確立できるフィールドが含まれていなければ、クライアントがインポートを完了できないという点です。これは、サブスクリプションリンクのリセットがすぐ効果を発揮する理由でもあります。サーバー側で認証情報が差し替わり、古いリンクのパラメータはその時点で無効になるからです。
| プロトコル | 認証情報の形式 | トランスポート層 | 説明 |
|---|---|---|---|
| Shadowsocks | パスワード + 暗号化方式 | TCP（UDP 転送も別途設定可能） | 構造がシンプルで、対応クライアントが幅広い |
| VMess | UUID | TCP（WebSocket / gRPC などのトランスポート層を重ねられる） | パラメータが多く、インポート時はトランスポート層の設定と組み合わせる必要がある |
| Trojan | パスワード | TCP、TLS を使用、ポートは通常 443 | 通信の特徴が通常の HTTPS に近い |
| VLESS | UUID | TCP、XTLS / Reality と組み合わせることが多い | 構造は VMess より簡素で、暗号化はトランスポート層に任せる |
| Hysteria2 | パスワードまたは認証文字列 | QUIC ベース、UDP を使用 | パケットロスが多い回線向けで、UDP の経路に依存する |
| TUIC | UUID + パスワード（v5） | QUIC ベース、UDP を使用 | Hysteria2 と同じく QUIC 系で、UDP の品質に影響される |
この表が示しているのはただ一点です。どのプロトコルを使っていても、サブスクリプションリンクには接続を直接確立できる認証情報が必ず含まれています。リンクがコピーされるということは、接続権限がコピーされるということであり、プロトコル自体の先進性とは関係ありません。
サブスクリプションのリセットがすぐ効く理由
サブスクリプションリンクはサーバー側で発行され、リセット操作はサーバー側でこの認証情報を差し替えます。古いリンクで設定を取得しようとしても、サーバーはもうそれを受け付けません。そのため、リセットは接続権限を切るための最も速い手段となります。一方、パスワード変更が影響するのはユーザーパネルへのログインだけで、すでに流出したサブスクリプションリンクを無効にすることはできません。両者の作用範囲は異なり、互いに代用できるものではありません。
「リンクを知っているのは自分だけ」という前提は、たいてい成り立ちません。サブスクリプションリンクはクライアント内に平文で保存されるほか、スクリーンショット、クリップボードの履歴、チャットのやり取り、サポートへの問い合わせ内容にも簡単に残ります。一度転送するたびに、接続権限を1つ複製して渡しているのと同じです。
公衆Wi-Fiの本当のリスクはどこにあるのか
公衆Wi-Fiのリスクは「電波を傍受される」といった漠然とした話ではなく、一つひとつ確認できる具体的なポイントにあります。以下では発生の仕組みごとに分けて並べ、暗号化トンネルがどこまでカバーできるかも併記します。
| リスク | 実際の発生の仕組み | トンネルで緩和できるか |
|---|---|---|
| 同一ネットワーク内での傍受 | 平文の HTTP リクエストが、同じネットワーク上の機器から読み取られる | 緩和される：通信がトンネルに入れば読み取れない |
| 偽のポータルログインページ | 偽ページが、ログインフォームに入力したIDとパスワードを収集する | 緩和されない：ログインはトンネル確立より前に行われる |
| 名前解決の書き換え | 解決結果が差し替えられ、見た目が同じ偽サイトへ誘導される | 名前解決がトンネルを通るかどうか次第で、別途確認が必要 |
| 同名のアクセスポイント | 端末が同じ名前の偽アクセスポイントに自動接続する | 緩和されない：システム設定で自動接続をオフにする必要がある |
表のうち2行は、トンネルでは解決できません。キャプティブポータルでは、まずWebページ上でログインを済ませないとトンネルを確立できず、この段階で入力した内容はアクセスポイントの運営者にそのまま渡ります。そのため公衆ネットワークでは、第一にシステムの「既知のネットワークに自動接続」をオフにし、第二にポータルページで重要なアカウントと同じパスワードを使わないことです。
ルーティングルールが、どの通信が実際にトンネルを通るかを決める
クライアントのルーティングルール（「分流ルール」と表記される画面もあります）は、どのリクエストをトンネル経由にし、どれを直接接続にするかを決めます。既定のルールでは、LAN内のアドレスやよく使う日本国内のサイトが直接接続に設定されていることが多く、速度は上がりますが、その分の通信はトンネルの保護を受けません。ルールの内容に確信が持てないときは、モードをグローバルに切り替えるほうが安全です。信頼できるネットワークに戻ったらルールモードに戻し、必要に応じて調整しましょう。
DNSリークも、別途確認が必要なポイントです
名前解決は、ドメイン名をアドレスに変換する役割を担います。トンネルがWebの通信だけを引き受け、名前解決のリクエストがローカルネットワーク側で処理されると、DNSリークが発生します。どのドメインにアクセスしたかがローカルネットワークから見えてしまううえ、返ってくるアドレスが書き換えられている可能性もあります。見分け方は簡単です。接続後に任意のDNSリークチェックページを開き、結果に表示されるリゾルバの地域が選択中の回線と一致しているかを確認してください。一致していなければ、名前解決がトンネルを通っていません。クライアント側で名前解決をトンネル経由に変更するか、クライアントの「リーク防止」オプションを有効にしてください。
プラットフォーム別クライアントの違い
デスクトップ向けクライアント（Windows、macOS）は一般に、ルールモードとアプリ単位の設定をひと通り備えており、調整できる項目が最も多くなっています。Android はアプリごとにトンネルを通すかどうかを選べます。iOS はシステムの仕組み上、ルールが構成プロファイルで決まるため、選べる粒度はデスクトップより粗く、グローバルとルールモードのどちらを使うかを早い段階で決めておく必要があります。Linux ではコマンドラインのクライアントが中心で、設定は手作業で維持する必要があります。認証情報の更新後に再インポートを忘れないよう、サブスクリプションリンクの更新周期をカレンダーに登録しておくことをおすすめします。
サポートが決して求めてはいけない情報
判断基準はただ一つ、相手が求めているものが問題の切り分けに本当に必要なのかどうかです。トラブルシューティングに実際に必要な情報はごくわずかで、それを超えるものは一切渡さないでください。
- ✅ 提供してよい：ユーザー名（パスワードではない）、注文番号、症状、クライアントとOSのバージョン、エラーメッセージ全文。
- ✅ 提供してよい：スクリーンショット。ただし送信前に、画面内にサブスクリプションリンク、QRコード、ノード情報が写っていないか確認してください。
- ❌ 提供しない：アカウントのパスワード。回線の状態確認にパスワードが必要になることは、どのような場合もありません。
- ❌ 提供しない：サブスクリプションリンクの全文。設定を確認したいときは症状だけを伝え、リンクは貼らないでください。
- ❌ 提供しない：決済アカウントのログイン情報、または支払い控えに記載されたカード番号の全体。
- ❌ 提供しない：身分証明書の写真。本人確認は、回線のトラブルシューティングに必要な手順ではありません。
別の見方をすれば、このリストはなりすましを見分けるのにも使えます。相手が上記の ❌ の内容を自ら求めてきたら、どんなに立派な理由を並べていても、いったん立ち止まり、自分で開いた公式の窓口から連絡相手を確認し直してください。本サービスの登録に必要なのはユーザー名とパスワードだけで、メールアドレスは不要ですし、追加の情報入力も求めません。この点自体が判断の材料になります。
認証情報の漏えいが疑われるときの対処順序
サブスクリプションリンクがグループに転送されていた、見覚えのない端末からアカウントにログインされていた、あるいは漏えいしたかどうか確信が持てない——いずれの場合も、以下の順序で対処してください。順序を入れ替えてはいけません。理由は各手順の後に記しています。
- まずユーザーパネルでサブスクリプションリンクをリセットします。流出した認証情報を即座に無効にする、接続権限をすぐに切れる唯一の操作です。
- 次にアカウントのパスワードを変更します。同じユーザー名とパスワードを他のサービスでも使っている場合は、そちらも併せて変更してください。認証情報の使い回しは、一度の漏えいを何度もの漏えいに広げてしまいます。
- パネル内の注文情報とログイン情報を確認します。本人が行っていない変更がないかを確かめてから、さらなる対応が必要かどうかを判断してください。
- 各端末で古い設定を削除し、新しいサブスクリプションをインポートし直します。古い設定は放っておいても自動では消えませんが、それが指す認証情報はすでに無効です。残しておくと接続失敗を繰り返すだけになります。
- エクスポートや転送をしたファイルを消します。チャット履歴に残ったリンク、クリップボードの内容、設定を保存したメモなども含みます。
安全の約束を検証できる事実に置き換える
初心者がサービスを選ぶとき、最も心を動かされやすいのは、耳当たりのよい決めつけの言葉です。しかしこうした言葉には検証できる意味がなく、誰でも書けます。より役に立つのは、相手がどのような検証可能な事実を公開しているかを見ることです。対応している国・地域の数、回線の数、返金期限の長さ、登録時に必要な情報、プライバシーポリシーで記録範囲をどう説明しているか——こうした点です。
この3つはそのまま比較できます。対応範囲は回線を選べる余地を決め、回線数はピーク時の使いやすさに影響し、返金期限は試行錯誤のコストを左右します。一方、安全に直結するのは実は別の2項目です。登録時にメールアドレスの提出が必要かどうか、そしてプライバシーポリシーで記録範囲をどう記述しているか。本サービスの場合、登録に必要なのはユーザー名とパスワードだけで、メールアドレスは不要です。プライバシーポリシーには閲覧内容を記録しない旨を明記しています。こうした記述は方針の表明であり、検証が可能で、検証できない保証として包装されることもありません。
冒頭の表に戻りましょう。アカウント、サブスクリプションリンク、クライアント設定は、それぞれ別の権限に対応しています。この3者の境界を覚えておけば、初心者のうちに避けられる落とし穴の大半をカバーできます。端末数や回線の選び方といった利用面の調整は、後回しにして少しずつ進めれば十分です。