サブスクリプションURLとは、クライアントが接続設定を取得するための専用アドレスです。支払い用のリンクでも一般的なウェブサイトでもありません。対応するクライアントに読み込ませると接続先一覧を取得できます。その後、接続先を選び、プロキシを有効にして、実際にアクセスできるか確認します。

ここでいう「サブスクリプション」とは設定を取得する方式であり、月額払いが必須という意味ではありません。6NVPNの月額プランは¥9.9 / 60GB、¥18 / 250GB、¥28 / 500GBで、利用開始日を基準に毎月通信量がリセットされます。永久通信量パックに有効期限はありません。URLを更新しても設定が更新されるだけで、契約の更新や使用済み通信量のリセットは行われません。

サブスクリンク・ノード・クライアントの違い

サブスクリプションURLは、接続設定を受け取るためのアドレスと考えるとわかりやすいでしょう。クライアントがこのアドレスにアクセスすると、対応形式のデータがサーバーから返されます。データにはノードのアドレスやポート、プロトコルのパラメーター、選択した設定形式に応じたルールなどが含まれる場合があります。URLにはアカウント固有の認証情報が含まれることが多いため、パスワードと同じように管理してください。

名称 主な用途 間違えやすい点
サブスクリプションURL 接続設定一式をリモートから取得・更新する コピーしただけではプロキシは有効にならない
単一ノードのリンク 特定の接続先の接続パラメーターを読み込む 通常、接続先一式を同期する機能はない
クライアント 設定を解析し、接続を確立して通信を振り分ける インストールできても、すべてのプロトコルに対応するとは限らない
ルーティングルール 通信をプロキシ経由・直接接続・その他の方式に振り分ける ノード一覧を更新しても、ルールが同時に更新されるとは限らない

もう一つの違いは「プロトコル」と「設定形式」です。Trojan、VLESS、Hysteria2などは接続方式を表し、サブスクリプションから返されるデータはクライアントが解析できる形式である必要があります。クライアントが特定のプロトコルに対応していても、別のクライアント向けの設定ファイル全体をそのまま読み込めるとは限りません。サブスクリプションの取得先を選ぶ際は、クライアント名・バージョン・プロトコルへの対応状況をあわせて確認しましょう。

URLの取得先とコピー前の確認事項

サブスクリプションはサービスのユーザーパネルから取得してください。チャット履歴や検索結果、不明なページから入手するのは避けましょう。6NVPNのユーザーはユーザーパネルにアクセスし、パネル内のサブスクリプション項目と使い方ガイドに従って操作できます。画面の名称はパネルの変更に伴い変わる場合があるため、現在の表示を確認してください。

パネルに複数のクライアント向け項目がある場合は、実際に使うクライアントに合ったものを選びましょう。コピーしたURLはクライアントのサブスクリプション欄にそのまま貼り付けてください。疑問符以降のパラメーターを手動で削除してはいけません。一見複雑な文字列が認証情報や形式の指定に使われている場合があります。また、URLを「修正」するためにユーザー名やパスワードを付け加えるのも避けてください。

  • ✅ 自分でログインしたサービスのユーザーパネルから取得したURLで、アカウントが設定を取得できる状態か確認する。
  • ✅ コピーしたものがサブスクリプションURLであり、パネルのウェブページURLや単一ノードの共有リンクではないことを確認する。
  • ✅ クライアントとそのバージョンが選択した形式に対応しており、説明文などを一緒に貼り付けていないことを確認する。
  • ❌ URL全体を公開チャットやフォーラムのスクリーンショット、不明なオンライン検査ページに載せない。

クライアントへの読み込み:URLから接続確認まで

ボタン名はクライアントによって異なりますが、「サブスクリプション」「設定」「リモート設定」「URLから読み込み」などの項目が一般的です。以下では操作の目的ごとに説明します。特定バージョンの画面上の位置を共通のルールとして扱わないでください。サーバー情報を手動入力する画面しかない場合は、単一ノードの編集画面を開いていないか確認しましょう。

  1. 対応するクライアントを用意する。公式サイトまたはパネルのダウンロード項目からアプリを入手します。読み込み前にプロトコルへの対応を確認し、設定の解析エラーを接続先の障害と取り違えないようにしましょう。
  2. リモートサブスクリプションを追加する。URL全体を貼り付け、見分けやすい名前を付けます。保存したら取得または更新を実行し、接続先一覧と成功メッセージが表示されるか確認してください。
  3. 読み込んだ設定を有効にする。クライアントによっては複数の設定を保存できるため、追加しても自動で切り替わるとは限りません。使用する設定が選ばれていることを確認してから、接続先またはポリシーグループを選びましょう。
  4. プロキシを有効にする。デスクトップではシステムプロキシやTUNの有効化が必要な場合があります。モバイルでは通常、システムのVPN設定への許可が求められます。クライアントの説明に従って選択し、すべてのモードを同時に有効にする必要はありません。
  5. 利用するアプリで動作を確認する。出口IPを確認したうえで、実際に使いたいウェブサイトやアプリを開きます。最後に、直接接続するアプリも正常に動作するか確認しましょう。「接続済み」の表示だけで判断しないことが大切です。

WindowsやmacOSのシステムプロキシでは、すべてのアプリの通信を処理できるとは限りません。システムプロキシの設定を無視するアプリもあります。TUNモードはより多くの通信を処理できますが、ルーティングや権限、除外ルールの影響を受けます。Androidではアプリごとのプロキシ設定によって対象アプリが変わり、iOSでもネットワーク拡張の権限やクライアントのルーティングルールが結果に影響します。あるプラットフォームのスイッチ名や設定を、別のプラットフォームにそのまま当てはめないでください。

出口を確認する場合は、サイト内のIPアドレス確認を利用できます。表示されるのは、その時点でブラウザーが行ったリクエストの出口IPです。すべてのアプリが同じ経路を使うとは限らないため、オフィスソフトやゲーム、コマンドラインツールは個別に確認してください。

更新の頻度と、通信量に影響しない操作

すべてのクライアントに共通する固定の更新間隔はありません。まずサービスのユーザーパネルとクライアントの案内に従いましょう。接続先一覧の変更、古いノードの停止、設定更新の通知、専用URLの再取得があった場合は、手動で更新してください。自動更新は更新忘れを防げますが、失敗した場合は何度もクリックするのではなく、エラー内容を確認しましょう。

「サブスクリプションの更新」は設定の再ダウンロード、「クライアントの更新」はアプリのアップグレード、「ルールの更新」は別のルールデータの再取得を指す場合があります。それぞれ別に実行できます。ノードのみを提供するサブスクリプションでは、更新後にローカルのルールが変わらなくても正常です。設定全体を提供する場合は、更新によってその中の設定が置き換わることがあります。

そのため、ローカルルールを変更する前に、クライアントが上書き・統合・独立したルールファイルに対応しているか確認してください。リモート設定から生成されたファイルを直接編集すると、次回の更新で変更が失われる場合があります。残しておきたいルールには、クライアントが正式にサポートする永続化方法を使い、現在の編集画面だけに頼らないようにしましょう。

判断の目安:接続先が変わったら設定を更新し、ソフトウェアの互換性に問題がある場合はクライアントのバージョンを確認し、通信量が足りない場合はプランの使用状況を確認します。URLの更新で通信量が戻るわけではなく、あらゆるネットワーク問題を解決できるわけでもありません。

読み込み失敗・接続できないときの症状別チェック

サブスクリプションの内容を取得できない

まず、リクエストが完了していないのか、データはダウンロードできたものの解析に失敗したのかを切り分けます。タイムアウトやドメイン名の解決エラーが出る場合は、現在のネットワークからサブスクリプションサーバーに接続できるか確認しましょう。明確な認証エラーが表示された場合は、パネルでアカウントとURLの状態を確認します。端末の時刻がずれているとHTTPS証明書の検証に影響することもあります。警告を回避するために証明書検証を無効にしないでください。

クライアントによっては、サブスクリプションの取得に直接接続またはプロキシを使う設定があります。以前の接続先が使えなくなった状態で更新リクエストがそのプロキシに依存していると、新しい設定を取得できないことがあります。クライアントの説明に従って取得経路を確認し、信頼できるネットワークで再試行してください。出所のわからない変換サービスを安易に使うのは避けましょう。

形式エラーまたはノードがないと表示される

ログインページやエラーページをコピーしていないか、形式が対応しているか確認します。URLをブラウザーで開けても、返される内容が使用中のクライアントに適しているとは限りません。反対に、ブラウザーに読みにくい文字列が表示されても、異常とは限りません。まずパネルでクライアントに合った項目を選び直し、アプリのバージョンも確認してください。

プロトコルごとに、対応するコア機能が必要です。設定ファイルの拡張子を変更しても、クライアントが本来対応していないプロトコルを利用できるようにはなりません。接続先の名称だけで接続方式を判断せず、設定内容とクライアントの認識結果を確認してください。

ノード一覧は表示されるが、アプリからアクセスできない

この場合、サブスクリプションのダウンロードは完了している可能性があります。接続先の選択、システムプロキシ、TUN、アプリごとの除外設定、ルールの適用状況を確認しましょう。まず別の利用可能なサイトを試し、ブラウザーと対象アプリで結果を比べてください。特定サイトの制限を設定全体の不具合と取り違えないようにします。

DNSについても個別に確認が必要です。出口IPが変わっても、ドメイン名の問い合わせが想定した経路で送信されるとは限りません。一方、ローカルDNSのアドレスが表示されても、それだけで漏洩が起きているとは判断できません。クライアントがローカルの待ち受け先で問い合わせを受け取り、その後転送している場合があるためです。DNSモードや問い合わせ先、アプリの実際の動作をあわせて確認しましょう。

URLが漏れたときの再発行と日常の管理

サブスクリプションURLを持つ人は、有効な設定を取得できる可能性があります。公開された場所に誤って投稿した場合は、まずパネルに認証情報のリセットまたは再発行機能があるか確認してください。確認できない場合は、サービスのサポートに状況を伝えましょう。投稿を削除したりクリップボードを消去したりしても、すでにコピーされたURLは無効になりません。

再発行後は、すべてのクライアントのURLを新しいものに更新し、古いサブスクリプションを削除します。そのうえで、古いURLが無効になったか確認してください。古いURLが無効になっても、他の人がすでに取得したノードの認証情報まで同時に無効になるとは限りません。サービス側の認証方式によるため、接続用の認証情報も失効させる必要があるかサポートに確認しましょう。

日常的な保管には信頼できるパスワード管理ツールを使い、平文のメモや複数端末間のクリップボードに残さないようにしましょう。サポートチケットでは、問題の調査に必要な情報だけを伝えてください。サポート担当者が機密性の高い設定を確認する必要がある場合も、完全なURLを公開せず、サービスの公式窓口を利用しましょう。

初心者向けの手順:公式パネルからURLを取得し、クライアントに合った形式を選んで設定を読み込み、有効化したら出口と対象アプリで動作を確認します。変更があったときに更新し、URLが漏れた場合は再発行して、認証情報の失効範囲を確認しましょう。手順を分けて考えると、問題を切り分けやすくなります。