サブスクリプションリンクは通常のウェブアドレスではない
サブスクリプションリンクとは、クライアントが回線情報を自動取得するための入口です。サーバーからクライアントへ動的な回線リストを渡し、ノード名、サーバーアドレス、ポート、プロトコルパラメータ、ルール分岐情報を定期的に取得します。対応クライアントにリンクを導入すると、クライアントがURLへアクセスして設定を読み込み、接続可能な回線をローカルのリストに整理します。
HTTPSで始まるURLのように見えますが、公開ウェブページとは用途が異なります。通常のウェブアドレスは共有や閲覧に適していますが、サブスクリプションリンクにはアカウントや契約権限を識別できるランダムな認証情報が含まれることがあります。リンクを入手した第三者は、管理画面のパスワードを再入力せずに、関連付けられた回線設定を取得できる可能性があります。そのため、解説ページのリンクやダウンロード先ではなく、アクセス認証情報として扱ってください。
サブスクリプションリンク自体は通常、通信トラフィックを運びません。クライアントはまずリンクから設定を取得し、実際に接続するときは設定に従って Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC などのプロトコルで該当する回線へ接続します。クライアントからサブスクリプションを削除しても、サーバー側の認証情報が無効になるとは限りません。古い認証情報による設定取得を止めるには、ユーザーパネルでリンクをリセットまたは取り消す必要があります。
サブスクリプション、ノード、プロトコルの関係
| 項目 | 役割 | よくある誤解 |
|---|---|---|
| サブスクリプションリンク | クライアントに回線リストと接続パラメータを渡し、その後の更新も担う | 接続そのものだと思い込む、または公開してよいウェブページとして扱う |
| ノード設定 | サーバーアドレス、ポート、認証情報、通信方式、回線名を記述する | 永久に変わらないと思い、サーバー側の調整後に更新が必要なことを見落とす |
| 接続プロトコル | クライアントとサーバーがデータを認証、カプセル化、送信する方法を定める | プロトコル名だけを見て、クライアントが関連パラメータを完全にサポートするか確認しない |
| ルール分岐 | どのドメインやアドレスをプロキシ、直接接続、ブロックのどれにするか決める | 回線接続中に、ルール分岐の誤りをノード障害と判断する |
一部のクライアントでは、ノードを1件ずつ導入することもできます。これは一時的な診断には適していますが、サブスクリプション管理の代わりにはなりません。回線名、入口アドレス、パラメータが変更されても、個別に保存した古いノードは自動同期されないためです。長期利用ではサブスクリプションの取得元を残し、手動ノードは主要設定ではなく、トラブルシューティング用の控えとして扱ってください。
ユーザーパネルから取得し、入手元を確認する
サブスクリプションリンクを取得するときは、まず PDDVPN のユーザーパネルからサブスクリプションまたはクライアント設定のページへ進んでください。検索結果、他人から転送された内容、不明な解説からコピーするのは避けます。パネルに表示されるリンクは現在のアカウントに紐づいており、リセット後も同じ場所から新しいリンクを取得できます。PDDVPNはメールアドレスなしで登録でき、設定したユーザー名とパスワードでパネルにログインできます。
- ユーザーパネルを開いてログインし、サブスクリプション情報またはクライアントのダウンロードページへ進みます。
- 使用するクライアントに対応した形式を選択します。汎用サブスクリプションと特定クライアント向けの形式がある場合は、現在のクライアント名または形式の説明に一致する入口を優先してください。
- コピー用ボタンでリンク全体を取得し、先頭、末尾、クエリパラメータの欠落を防ぎます。
- クライアント内の「URLから導入」「サブスクリプションを追加」などの入口に貼り付けます。単一ノードのアドレス欄には入力しないでください。
- 初回更新が完了したら、回線名とサブスクリプションの取得元を確認し、回線を選んで接続テストを行います。
コピー後に改行、空白、末尾の文字欠落があると、クライアントに形式エラー、ネットワークエラー、空のサブスクリプションなどが表示されることがあります。この場合、リンクの文字を何度も手作業で修正したり、トークンを推測したりしないでください。入力欄を空にして、パネルから完全な内容をもう一度コピーするのが最も確実です。
- ✅ リンクは現在ログインしている公式ユーザーパネルから取得している。
- ✅ 導入入口にサブスクリプション、URL、リモート設定などの表示があり、単一ノード用ではない。
- ✅ クライアントの初回更新後に回線名とサブスクリプションの取得元が表示される。
- ❌ 完全なサブスクリプションリンクを、いわゆるオンライン変換ツールに渡さない。
- ❌ アドレス欄、QRコード、サブスクリプション詳細を公開スクリーンショットに載せない。
- ❌ 入手元が不明な複数のクライアント間で、同じ認証情報を繰り返しコピーしない。
主要5プラットフォームへの導入経路と違い
OSによってネットワーク拡張、バックグラウンド更新、設定保存に関する制限が異なるため、ボタン名や許可の手順は完全には一致しません。導入の基本手順は共通しています。リモートサブスクリプションを追加し、更新を実行し、回線を選び、システムにVPNまたはプロキシ設定の作成を許可したうえで、出口とDNSが想定どおりか確認します。
Windows
Windowsクライアントでは通常、「設定」「サブスクリプション管理」「設定ファイル」などのメニューからURL導入を選択できます。追加後はまずサブスクリプションを更新し、システムプロキシ、仮想ネットワークアダプター、またはクライアントの接続モードを切り替えます。クライアント画面を開くだけで該当モードを有効にしていない場合、ブラウザの通信が直接接続のままになることがあります。
企業ネットワークにカスタム証明書、フィルタリングソフト、厳格なファイアウォールが導入されていると、サブスクリプションの取得とノード接続がそれぞれ影響を受ける可能性があります。サブスクリプションを更新できても、回線に接続できるとは限りません。反対に、ローカルに保存済みのノードへ接続できても、リモートのサブスクリプションが有効とは限りません。切り分けでは「設定の取得」と「トンネルの確立」を分けて確認してください。
macOS
macOSクライアントで初めて接続するときは、通常、ネットワーク拡張またはVPN設定の許可が必要です。Appleシリコン搭載端末とIntel端末では画面が多少異なる場合がありますが、現在のシステムバージョンに合った正式ビルドを優先してください。サブスクリプションの導入後に許可ダイアログが表示されない場合は、システム設定のネットワークまたはプライバシー関連の項目で、該当する拡張機能の実行が許可されているか確認します。
システムプロキシに設定されたアプリだけを制御するクライアントもあれば、ネットワーク拡張によってより広範な通信を処理するクライアントもあります。ブラウザの挙動は変わったのに、コマンドラインツール、同期サービス、App Storeの動作が異なる場合は、すぐにサブスクリプションをリセットするのではなく、制御モードとルール分岐を確認してください。
iOSとiPadOS
モバイルOSではVPN設定の作成が求められ、システムレベルの確認によって許可を完了します。サブスクリプションリンクはクライアントのリモート設定入口に貼り付けてください。クリップボードから導入した場合は、完了後に機密性のない別の内容でクリップボードを上書きすると、別の操作で誤貼り付けされるリスクを抑えられます。
システムの省電力機能やバックグラウンド制限により、サブスクリプションが想定した時間に自動更新されないことがあります。回線リストが古い場合は、まずクライアントを開いて手動更新してください。システム上はVPN接続中でも対象アプリが元の経路を使う場合は、アプリ別ルール、ドメイン分岐、クライアントのグローバルモードまたはルールモードを確認します。
Android
Androidクライアントでは、導入後にVPN接続リクエストの許可も必要です。メーカーによってバックグラウンド実行や省電力設定の扱いが大きく異なり、クライアントプロセスが終了することがありますが、これはサブスクリプション認証情報が無効になったこととは別です。クライアントを再び開いたら、まずサブスクリプションが残っていることを確認し、手動更新と再接続を行います。
クライアントが共有導入やQRコードの読み取りに対応していても、自分の画面と端末の間だけで操作してください。公開画像認識サービスでQRコードを処理すると、完全な認証情報が別の処理事業者に渡るため、通常の導入方法には適しません。
Linux
Linuxにはグラフィカルクライアントのほか、コアプログラムが設定を読み込む方法もあります。デスクトップ環境ではリモートサブスクリプション管理に対応したクライアントを選べます。サーバーやコマンドライン環境では、使用するツールがサブスクリプションの取得、形式変換、ルール読み込みに対応しているか確認してください。任意のコアプログラムがパネルから返された形式を直接読み込めるとは限りません。
コマンドラインで設定を取得するときは、シェル履歴、プロセス引数、ログ出力にも注意が必要です。完全なリンクを他のユーザーが読めるスクリプトやコマンド履歴に直接記録すると、認証情報の露出範囲が広がります。現在のユーザーだけが読める設定ファイルを使い、リクエストURLをログに出力するかどうかも制御するのが安全です。
| プラットフォーム | 導入後に確認するポイント | 主なシステム上の違い |
|---|---|---|
| Windows | サブスクリプションが更新され、システムプロキシまたは仮想ネットワークアダプターのモードが有効になっている | ファイアウォール、証明書フィルタリング、制御モードの違い |
| macOS | ネットワーク拡張またはVPN設定がシステムで許可されている | システムプロキシとネットワーク拡張では、対象となる通信範囲が異なる |
| iOS / iPadOS | VPN設定が作成され、ルールモードが用途に合っている | バックグラウンド更新とシステムの省電力制限 |
| Android | VPNリクエストが許可され、クライアントが省電力設定で終了されていない | メーカーごとのバックグラウンド管理方針の違い |
| Linux | ツールがサブスクリプション形式に対応し、設定ファイルの権限が制限されている | グラフィカルクライアントとコアプログラムでは機能が異なる |
プロトコル、回線種別、サブスクリプション形式の連携
サブスクリプションが返す内容は、クライアントによって正しく解析される必要があります。クライアントが回線名を認識できても、設定に含まれるすべての通信パラメータをサポートするとは限りません。同じプロトコル名でも、トランスポート層、TLS、UDP、その他の拡張機能が一致しないと、導入は成功しても接続に失敗することがあります。対応状況はプロトコルと通信方式の組み合わせまで確認し、「サブスクリプション対応」という表示だけで判断しないでください。
Shadowsocksは暗号化方式やパスワードなどのパラメータでプロキシ接続を確立します。VMessは比較的初期の関連エコシステムでよく使われます。Trojanは通常TLSと組み合わせ、パスワード方式で認証します。VLESS自体はコンテンツを暗号化せず、実際の安全性はTLS、REALITYなどの対応トランスポートと正しい設定に依存します。Hysteria2とTUICはQUICとUDPを基盤とするため、現在のネットワークで安定したUDP通信が許可されるかどうかに左右されます。クライアントの対応表は、プロトコルと通信方式の組み合わせまで具体的に確認し、「サブスクリプション対応」の4文字だけで判断しないでください。
回線種別はネットワーク経路を表すもので、プロトコルとは異なります。直接接続の回線はローカルから遠隔の入口へ直接接続するため経路が単純ですが、現地の通信事業者や国際出口の変動を受けやすくなります。中継回線は近隣の中継入口にいったん接続してから対象地域へ転送し、国際経路を調整しやすくします。IEPL専線は国際区間に専用の伝送経路を使う点が特徴で、公開ネットワークの直接接続とは調整方法が異なるのが一般的です。ただし、最終的な利用感は現地アクセス、クライアントの状態、対象サービス、現在の回線構成にも左右されます。
「プロトコル」はデータのカプセル化と認証方法を、「回線」はデータが通るネットワーク経路を、「サブスクリプション形式」はクライアントが設定を受け取る方法を示します。3つすべてに互換性が必要です。
サブスクリプション更新後に回線名が変わる場合、サーバー側での再グループ化、入口の移行、回線ラベルの調整が考えられます。名前だけで設定が完全に同じだと判断せず、サブスクリプションから削除された古いノードを長期間固定して使わないでください。特定地域の出口が必要な場合は、地域と回線種別で選び直し、接続後に実際の出口を確認します。
サブスクリプションを更新するタイミングと、更新失敗時の確認方法
サブスクリプションに、すべてのクライアント共通の更新間隔はありません。起動時に更新するもの、ローカル設定に従うもの、ユーザーが手動操作したときだけ取得するものがあります。適切なのは頻繁に更新することではなく、初回導入時、回線リストが明らかに古いとき、サーバー側の変更通知を受けたとき、接続異常の原因として古い設定を除外したいときに更新することです。
更新するとサブスクリプションURLへ再リクエストが送られますが、ローカル設定がすべて自動的に上書きされるとは限りません。クライアントが作成したグループ、ルール分岐、DNS設定、回線選択は残る場合もあれば、実装によって再構築される場合もあります。重要なカスタムルールは、先にエクスポートまたはバックアップ方法を確認してください。
- 端末自体からユーザーパネルにアクセスできることを確認し、基礎ネットワークが完全に停止していないか切り分けます。
- サブスクリプションの取得元が、特にリセット後もパネルに現在表示されているリンクか確認します。
- 貼り付け時に生じた空白と改行を削除します。完全性を確認できない場合は手作業で補修せず、もう一度コピーしてください。
- クライアントのエラーが、ダウンロード失敗、解析失敗、接続失敗のどれに該当するか確認します。3種類で対処の方向が異なります。
- ダウンロードに失敗する場合は、システム時刻、証明書の傍受、ネットワークフィルタリング、クライアントのネットワークアクセス権を確認します。
- 解析に失敗する場合は、サブスクリプション形式とクライアントの互換性を確認し、対応しているクライアントバージョンへ更新します。
- 一部の回線だけが失敗する場合は、サブスクリプションを残したまま同じ地域の別回線へ切り替えます。設定全体を先に削除する必要はありません。
パネルは開けるのにサブスクリプションが継続して空の内容を返す場合は、まずプランまたは通信量の状態を確認します。そのうえで、発生時刻、クライアント名、システムバージョン、匿名化したエラー情報を問い合わせフォームから送ってください。問い合わせ本文に完全なサブスクリプションリンクを記載しないでください。担当者による確認が必要な場合は、問い合わせ内の安全な案内に従ってください。
接続後にDNS漏えいとルール分岐を確認する
回線が接続済みと表示されても、クライアントがトンネルまたはプロキシの確立を認識しているだけです。想定する通信が実際に制御されているか確認するには、出口IP、DNSの名前解決経路、ルール分岐を調べる必要があります。DNS漏えいとは通常、対象ドメインの名前解決リクエストが想定どおりプロキシ側または指定DNSへ渡らず、ローカルネットワーク経由で処理され続ける状態を指します。アクセス先のドメインが露出したり、出口地域と一致しない名前解決結果が対象サービスに返されたりする可能性があります。
DNSに異常がある場合は、サブスクリプションを再生成する前に、クライアントのDNSモードとルールを確認します。サブスクリプションは回線設定を提供しますが、DNSポリシーはクライアントや設定テンプレートが管理することが多いためです。システム上で他のネットワークツール、カスタムDNSサービス、ブラウザのセキュアDNSが同時に動作している場合、複数の名前解決経路が生じることもあります。
- ✅ 接続前後で出口IPを確認し、対象アプリが想定した回線を実際に使っていることを確認する。
- ✅ DNSの結果が、現在のルールモードと出口地域に一致しているか確認する。
- ✅ 直接接続すべきドメインとプロキシを通すべきドメインをそれぞれテストし、ルールの適用方向が正しいことを確認する。
- ✅ テスト後にクライアントのモードを記録し、回線切り替え時にグローバルや直接接続へ誤変更しないようにする。
- ❌ 「ノードの遅延が表示される」ことを、すべてのアプリが制御されている証拠だと考えない。
- ❌ DNS異常時に、同じサブスクリプションをむやみに繰り返し導入しない。
ルール分岐は通常、ドメイン、IP、アプリ、ルールセットなどに基づいて経路を決定します。対象サイトの一部リソースは開くのに別のリソースが失敗する場合、メインドメインと静的リソースのドメインが異なる経路に振り分けられている可能性があります。クライアントの接続ログで各リクエストのルール適用結果を確認し、ルールの取得元またはモードを調整してください。ログでの確認が終わったら、アクセス先ドメイン、サーバーアドレス、ローカルネットワーク情報が含まれる可能性があるため、ログの削除にも注意します。
サブスクリプションリンクが漏えいした場合の対処手順
完全なリンクを公開場所に投稿した、不信頼なツールに読み取らせた、他人がアクセスできるログに残った場合は、認証情報の漏えいとして扱ってください。公開メッセージを削除するだけではコピーが消えたとは確認できず、自分の端末からサブスクリプションを削除しても古いリンクが停止するわけではありません。重要なのはサーバー側で取り消すかリセットすることです。
- すぐにユーザーパネルを開き、「サブスクリプションをリセット」「サブスクリプションリンクを更新」などの機能を使って、古いリンクを無効にします。
- 自分のクライアントから古いサブスクリプションの取得元を削除します。以後の更新エラーを防ぎ、古い設定を現在の設定と取り違えないためです。
- パネルで生成された新しいリンクをコピーし、引き続き使用する信頼できる端末に再導入します。
- 他の端末と自動化設定を確認し、スクリプト、バックアップ、同期ツールが古いリンクを参照し続けていないことを確認します。
- 漏えいの原因がパネルのログイン状態やパスワードの露出にある可能性がある場合は、アカウントのパスワードも変更し、使用しなくなったセッションからログアウトします。
- パネルのサブスクリプション状態と端末の利用状況を確認し、説明できない異常があれば匿名化した情報を問い合わせフォームから送ります。
スクリーンショットで漏えいした場合は、元画像、クラウド共有コピー、チャット履歴内の添付ファイルを同時に削除します。コードリポジトリやスクリプトで漏えいした場合は、削除変更を1回コミットするだけでは履歴を消去できません。先にサーバー側の認証情報をリセットし、その後でリポジトリの履歴とデプロイ環境を処理してください。対処の順序は、まず認証情報を無効にし、その後で拡散したコピーを整理します。
再度の漏えいを減らすため、サブスクリプションを公開メモ、ブラウザの同期ブックマーク、複数人で共有するドキュメントに記載しないでください。端末を移行するときは、チャットツールで古いリンクを転送するより、新しい端末からパネルへ直接ログインして取得するほうが安全です。端末を停止する前にクライアント設定を削除し、紛失または回収できない場合はサブスクリプションを直接リセットしてください。
サブスクリプション管理を定型作業にする
サブスクリプション管理で頻繁に設定を変える必要はありませんが、取得元を明確にし、クライアント互換性を確保し、更新を管理でき、認証情報を取り消せる状態にしておく必要があります。初回導入時にはクライアント名、システムの制御モード、ルール分岐方式を記録します。回線異常時は、サブスクリプションのダウンロード、設定解析、ノード接続、DNS、ルール適用を切り分けます。端末を交換するときはパネルから再取得し、漏えいに気づいたらすぐにリセットしてください。
最もよくある誤りは、すべての異常をサブスクリプションリンクのせいにすることです。実際には、リンクが有効でもプロトコルが非対応、回線に接続できてもDNS経路が誤っている、ルールモードが用途に合っていないといった原因で、「機能していないように見える」結果になります。設定の配信、接続の確立、通信の制御、名前解決経路の順に段階ごとに確認すると、削除と再導入を繰り返すより問題を特定しやすくなります。
長期間使う端末では、取得元が明確なサブスクリプションだけを残し、テスト設定や無効なコピーを適時削除してください。これにより古い回線を選ぶミスを防ぎ、リセットが必要になったときに再導入すべき端末をすぐ確認できます。サブスクリプションリンクは管理できる認証情報です。どこから取得し、どう検証し、いつ更新し、どのように取り消すかを把握してこそ、回線の運用を明確に保てます。