サブスクリプションリンクとは：取得・インポート・更新ガイド

サブスクリプションリンクとは、クライアントが回線設定を読み込むための入口です。通常はサーバー側で発行され、クライアントがノード名、サーバーアドレス、ポート、プロトコルのパラメータ、ルール分岐に必要な情報を取得します。設定を一つずつ手入力する必要はなく、アカウントパネルからサブスクリプションリンクをコピーして対応クライアントにインポートすれば、現在利用できる回線一覧を取得できます。

サブスクリプションリンクは特定の回線そのものでも、接続プロトコルそのものでもありません。更新可能な設定リストに近いものです。サーバー側で回線が調整された後、クライアントでサブスクリプションを更新すれば、最新のリストを再取得できます。この違いを理解しておくと、「サブスクリプションを更新できない」「ノードに接続できない」「ウェブサイトの表示に問題がある」といった別々の問題を切り分けやすくなり、クライアントを何度も削除する必要もありません。

重要な違い サブスクリプションは設定を配布し、プロトコルは接続を確立し、回線の種類はデータが通るネットワーク経路を決め、ルール分岐はどのリクエストでその接続を使うかを決めます。互いに関係はありますが、同じ概念として扱うことはできません。

サブスクリプションリンクに含まれる情報、含まれない情報

クライアントがサブスクリプションリンクをリクエストすると、汎用リンクの集合が返る場合もあれば、Clashやsing-boxなどが読み取れる構造化設定が返る場合もあります。具体的な形式はサーバーとクライアントの組み合わせで決まります。同じアカウントパネルに複数形式の入口が用意されている場合は、「サブスクリプション」と書かれたボタンを無作為にコピーするのではなく、クライアントが明確に対応している形式を選んでください。

サブスクリプションには通常、回線名、接続先アドレス、ポート、通信方式、暗号化または認証パラメータ、クライアントがプロキシグループを作成するためのタグが記載されます。形式によっては、ルールグループ、リモートルールのURL、DNSに関する推奨設定も含まれます。完全なルール分岐が含まれるかどうかはサーバー側の生成方式次第です。ノードだけを提供し、分岐をクライアント側のローカル設定に任せるサブスクリプションもあります。

よく使われるプロトコルにはShadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICがあります。プロトコル名が取得結果に含まれることはありますが、サブスクリプションリンク自体がこれらのプロトコルを「実行」するわけではありません。クライアントがまずサブスクリプションを解析し、各ノードに対応するプロトコルで接続を作成します。クライアントが特定のプロトコルや必要な通信パラメータに対応していなければ、サブスクリプションをダウンロードできても、そのノードは利用できない場合があります。

サブスクリプションは通常、クライアント画面にあるすべての設定を保存するものではありません。起動時の動作、ローカル待受方式、システムプロキシのオン・オフ、自作ルールなどは対象外の場合があります。更新時、クライアントはサブスクリプションから生成されたノードやプロキシグループを置き換えることがありますが、ローカル設定全体を自動修正するわけではありません。更新後に動作が変わった場合は、サブスクリプションの内容とクライアントのローカル設定を併せて確認してください。

ログイン後にサブスクリプションリンクを正しく取得する方法

安全に取得するには、サービス公式サイトからアカウントパネルへ入り、サブスクリプションまたはクライアントのダウンロード欄で、現在使うクライアントに合う形式を選びます。チャット履歴、検索結果のキャッシュ、他人から転送されたページからリンクを取得するのは避けてください。古いリンクや、現在のクライアントに適さない設定である可能性があります。

1. ijvpnの公式ページからユーザーパネルへ進み、ログインします。
2. サブスクリプションまたはダウンロード欄を開き、使用するOSとクライアントの種類を確認します。
3. クライアントが対応するサブスクリプション形式を選び、コピー機能でリンク全体を保存します。
4. クライアントに切り替え、「リンクからインポート」「リモート設定」など、同様の意味を持つ入口から追加します。
5. 初回更新が完了したら、ノード一覧が表示されることと、プロキシモードおよびルール分岐を確認します。

コピーする際はリンクを手動で切り取らず、意味がなさそうに見える末尾の文字も削除しないでください。サブスクリプションアドレスには、アカウント権限を識別するトークンが含まれていることがあります。一部でも欠けると認証に失敗する可能性があります。パネルにQRコードがある場合、それは同じサブスクリプション情報をスキャンしやすい形にしたもので、権限を変更するものではありません。

サブスクリプションリンクはアカウント認証情報の一部として扱ってください。公開投稿、スクリーンショット、コードリポジトリ、クラウド文書、複数人が閲覧できるメモに掲載するものではありません。サポートへ問い合わせる際も、エラーメッセージやクライアントログの非機密部分を優先し、リンク全体を直接貼り付けないでください。

コピー前に形式を確認 クライアントでリンクを開けても、すべてのノードを解析できるとは限りません。パネルに汎用サブスクリプションと専用設定の両方がある場合は、クライアントのドキュメントで対応が明記された形式を優先してください。

Windows、macOS、Android、iOSで異なるインポート方法

プラットフォームによって操作名は異なりますが、基本的な流れは同じです。リモート設定を新規作成し、サブスクリプションリンクを貼り付け、更新を実行してノードを選び、必要に応じてシステムプロキシまたは仮想ネットワークアダプターを有効にします。重要なのはボタンの場所ではなく、クライアントが対応する設定形式、プロトコルの範囲、ネットワークを引き継ぐ方法です。

デスクトップ：システムプロキシと仮想ネットワークアダプターを見分ける

WindowsとmacOSのクライアントには、システムプロキシと仮想ネットワークアダプターの両方が用意されていることがあります。システムプロキシは主にOSのプロキシ設定に従うアプリに影響し、設定は簡単ですが、一部のソフトウェアはその設定を読み取りません。仮想ネットワークアダプターはより広範な通信を引き継げるため、統一した分岐が必要な場面に適しています。ただし、追加のシステム権限が必要なことが多く、他のネットワークツール、企業向けセキュリティソフト、既存の仮想ネットワークアダプターと競合しやすくなります。

デスクトップでインポートした後は、まずリモート設定の最終更新日時が正常に更新されているか確認し、その後ノード一覧を開きます。ノードがあるのにブラウザーでアクセスできない場合は、システムプロキシの有効化、分岐モード、ブラウザー独自のプロキシ設定を確認してください。クライアントに「接続済み」と表示されただけで、システム全体の通信が選択した回線を通っていると判断しないでください。

モバイル：システム権限とバックグラウンド制限を確認

AndroidとiOSのクライアントは通常、OSが提供するVPNインターフェースを通じて通信を引き継ぎます。初回接続時には、システムからネットワーク設定の権限確認を求められます。サブスクリプションをインポートした後、アプリを切り替えると頻繁に切断される場合は、サブスクリプションが無効になったとすぐ判断せず、バックグラウンド動作の制限、省電力設定、ネットワーク切り替え時の動作を確認してください。

モバイルではQRコードからのインポートが便利ですが、アカウントパネルに直接表示された内容だけをスキャンしてください。QRコードが写真アプリに保存されたり共有スペースに同期されたりすると、完全なリンクを公開するのと同じリスクがあります。端末を交換した後は、古いスクリーンショットに頼らず、パネルから新たに取得することをおすすめします。

画面の似ていることよりクライアントの互換性が重要

複数のクライアントが「サブスクリプション」に対応していても、プロトコル、トランスポート層、ルール構文への対応状況は異なります。あるクライアントがShadowsocksとTrojanを読み取れるからといって、サブスクリプションに含まれるVLESS、Hysteria2、TUICのノードにも必ず対応するとは限りません。プロトコル名に対応していても、すべての拡張パラメータと互換性があるとは限りません。一部のノードが消えた場合は、再インポートする前にクライアントのバージョン情報とサブスクリプション形式を確認してください。

• インポート前に、クライアントの入手元とOSのバージョンが適合していることを確認します。
• クライアントが、サブスクリプションで実際に使われているプロトコルと設定形式に対応していることを確認します。
• 更新後、ノード数が大きく変化していないか、プロキシグループに選択肢が残っているか確認します。
• デスクトップでは、システムプロキシ、仮想ネットワークアダプター、ローカルファイアウォールの関係を確認します。
• モバイルでは、システムのネットワーク権限、バックグラウンド制限、Wi-Fi切り替え後の状態を確認します。

サブスクリプションを更新するタイミング

サブスクリプションは接続のたびに更新する必要はありません。通常、クライアントは最後に正常取得した設定を保持するため、サブスクリプションサーバーへ一時的にアクセスできなくても、ローカルに保存されたノードを使い続けられる場合があります。更新の主な目的は、回線の調整、名称変更、プロトコルパラメータの変更、削除された設定を取得することです。

アカウントパネルで設定変更の通知がある場合、ノード一覧がパネルと一致しない場合、複数のノードで同時に認証エラーが出る場合、または長期間更新していないクライアントを再利用する場合は、手動で更新してもよいでしょう。特定のサイトだけ開けない、特定の回線の速度だけ変わった、現在のネットワークで一時的にパケットロスが起きた、といった問題はサブスクリプションのバージョンと無関係な場合があります。何度も更新しても、回線層の問題は通常解決しません。

更新に失敗したら、まず「ダウンロード失敗」か「解析失敗」かを区別します。ダウンロード失敗は、現在のネットワーク、DNS、システム時刻、リンクの無効化、アクセス権限に関係することが多く、解析失敗は、サブスクリプション形式とクライアントの非互換、内容の途中欠落、クライアントが新しい項目を認識できないことが原因になりやすいです。

直結・中継・IEPL専線の違い

サブスクリプション一覧のノード名には、直結、中継、IEPL専線などの表示が付くことがあります。これらはネットワーク経路を表すもので、サブスクリプション形式ではありません。直結は通常、利用者のネットワークから海外サーバーへ直接接続する方式です。経路構造はシンプルですが、実際の品質はローカル通信事業者から対象地域までの公衆ネットワーク経路に大きく左右されます。

中継回線では、まず近い場所や経路条件のよい入口へ接続し、そこから中継ネットワークを通って出口へ到達します。公衆ネットワークでの迂回やネットワーク間接続を改善することが主な目的ですが、中継だから自動的に高速になるわけではありません。入口と出口の位置、現在のネットワーク、利用時間帯が結果に影響します。

IEPLは、企業向け国際専線またはそれに関連する伝送方式を表す際によく使われ、一般的な公衆ネットワークの直結とは経路の構成が異なります。一般利用者にとっては、名称だけで品質を判断せず、対象地域、利用アプリ、実際の接続状況を確認するのが実用的です。回線の表示はローカル環境でのテストに代わるものではありません。同じ回線でも、接続するネットワークによって結果が変わることがあります。

選ぶ際は、まず地域と用途で候補を絞り、実際のアクセス結果を比較します。文章作成やウェブ閲覧では接続の安定性と名前解決の正常さが重要です。会議、リアルタイム協業、継続的なアップロードでは、ジッターと切断の少なさが重視されます。大容量ファイルの転送は、ローカル回線の帯域、サーバー側の速度制限、国際経路のすべてから影響を受けます。サブスクリプションは選択肢を提供しますが、こうした客観的なネットワーク条件をなくすものではありません。

ルール分岐とDNSリークの確認方法

サブスクリプションをクライアントにインポートした後は、グローバル、ルール、直結などの動作方式を選ぶ必要があります。グローバルモードはより多くのリクエストをプロキシ回線へ送るため、短時間の分岐エラーの切り分けに適しています。ルールモードはドメイン、ネットワークアドレス、アプリの一致結果に応じて経路を決め、日常利用に向いています。直結モードは通常、クライアント設定を残したままプロキシを停止する際に使います。

分岐エラーでは、国際サイトが選択した回線を通らない、国内サービスが誤って海外出口へ送られる、同じページ内の異なるリソースが別々の経路を通る、といった症状が見られます。切り分けでは、一時的にグローバルモードへ切り替えて比較します。グローバルモードでは正常でルールモードだけ異常なら、問題はサブスクリプションそのものより、ルールの一致、ルールのバージョン、DNSの結果にある可能性が高いです。

DNSリークとは、ドメイン問い合わせが想定した経路で処理されず、使用したくないDNSリゾルバーへ送られ続ける状態です。地域判定の不一致、プロキシ出口と異なるDNS結果、ローカルネットワークで使われる名前解決環境の露出につながる可能性があります。これを避けるには、クライアントのDNSモード、ルール分岐、システムのネットワーク引き継ぎ方式を一致させる必要があります。

システムDNSだけを変更しても、必ずしも問題は解決しません。ブラウザーが独自の暗号化DNSを有効にしている場合や、クライアント自身にDNSモジュールがある場合もあります。確認時は、クライアントのDNS設定、ブラウザー独自の設定、システムのネットワーク設定、仮想ネットワークアダプターが問い合わせを実際に引き継いでいるかを順番に確認します。変更後は古いDNSキャッシュを消去して接続を再確立し、キャッシュ結果を現在の設定と誤認しないようにしてください。

• 対象ドメインが最終的にプロキシ、直結、拒否のどのルールに一致しているか確認します。
• クライアントが現在のモードに合ったDNS設定を使っているか確認します。
• ブラウザーがクライアントを迂回して独自の名前解決経路を使っていないか確認します。
• グローバルモードとルールモードを切り替えて比較し、問題の範囲を絞ります。
• ルール更新後に再接続し、古いキャッシュが判断に影響しないようにします。

サブスクリプションリンクが漏えいした場合の対処

完全なサブスクリプションリンクが公開スクリーンショット、共有文書、公開リポジトリ、転送範囲を確認できないメッセージに含まれていた場合は、認証情報が漏えいしたものとして扱います。公開内容を削除するだけでは不十分です。リンクがコピーまたはキャッシュされている可能性があるためです。安全な方法は、アカウントパネルにログインし、サブスクリプションのリセット、リンクの再生成、旧リンクの無効化などの機能を使って、既存のトークンを無効にすることです。

リセット後は、パネルから新しいリンクをコピーして、自分のクライアントで旧サブスクリプションと置き換えます。クライアントによってはリモート設定とローカル名が紐づいているため、アドレスを直接編集できます。別のクライアントでは、古いリモート設定を削除してから再インポートする必要があります。置き換え後に更新を実行し、ノードを正常に取得できることを確認してから、メモ、クリップボードの同期履歴、古いQRコードを削除します。

パネルに明確なリセット入口がない場合は、サポートページから問い合わせを送り、サブスクリプションリンクが漏えいした可能性と旧認証情報の無効化を依頼してください。説明に完全な旧リンクを添付する必要はありません。アカウント内でサブスクリプションを特定できる情報と、漏えいした状況を伝えれば十分です。

クライアント名を変更するだけでは不十分 リモート設定の名前を変更しても、サーバー側のトークンは変わらず、外部に漏れたリンクも無効になりません。実際に有効な対処は、古いサブスクリプション認証情報を無効化し、新しいリンクを管理下の端末へインポートすることです。

サブスクリプション更新失敗の確認手順

効果的な切り分けは、サブスクリプション層から始め、クライアント、プロトコル、回線、対象サイトへと段階的に進めます。一度に変更する条件を一つに絞ることで、どの設定が作用したのか分かります。複数のスイッチを何度も切り替えたり、すべての設定を削除したり、同時にクライアントを変更したりすると、比較に必要な情報を失うことがあります。

1. アカウントパネルに戻り、サブスクリプションが利用可能な状態か確認して、アドレス全体を再コピーします。
2. 現在のネットワークで更新を試し、クライアントにネットワークエラー、認証エラー、解析エラーのどれが表示されるか記録します。
3. インポート形式がクライアントに合っていることを確認し、クライアントがサブスクリプション内のプロトコルに対応しているか確認します。
4. 更新に成功したら、まず一つの回線を選んで基本接続をテストし、複雑な自作ルールはまだ追加しません。
5. 基本接続が正常になってから分岐を戻し、DNS、ブラウザー独自のプロキシ、システムのネットワーク引き継ぎ方式を確認します。
6. 複数の回線で同じ症状が出る場合に限り、ローカルネットワーク、システム時刻、ファイアウォール、他のネットワークツールとの競合を確認します。

サブスクリプションを更新でき、ノードにも接続できるのに特定のサイトだけ異常がある場合は、対象サイトの地域別ポリシー、キャッシュ、アカウント地域、ブラウザー環境、分岐結果が原因かもしれません。この場合、サブスクリプションを再設定し続けても通常は解決しません。まず別の回線とキャッシュを使わないセッションで比較し、そのサイトへのリクエストが想定した出口を実際に通っているか確認してください。

クライアントログにサーバーアドレス、認証情報、サブスクリプショントークンが含まれている場合は、提出前にマスキングしてください。エラーの種類、発生段階、時系列を残せば、問題の特定には十分なことが多いです。完全な機密設定を公開の掲示板へ貼り付けないでください。

サブスクリプションリンクを安全に使うための習慣

サブスクリプションリンクの利点は、手動設定を減らし、回線情報を更新可能な状態に保てることです。ただし、その利便性は適切なクライアントと認証情報の管理が前提です。日常利用では、公式パネルから設定を取得し、クライアントが対応する形式を選び、必要なときに更新してください。リンクを複数のツールへ長期間分散させるのは避けましょう。

端末を移行する際は、まずパネルへ再ログインしてサブスクリプションを取得してください。古い端末を使わなくなる前に、そこにあるリモート設定を削除します。ネットワーク利用の知見を共有する場合は、プロトコルの種類、エラー情報、認証情報を含まない設定項目だけを示してください。リンクが管理範囲外に出た疑いがあるなら、異常が起きるまで待つより、すぐにリセットするほうが安全です。

最後に、サブスクリプションの取得に成功したことは、クライアントが設定を取得できたことを示すだけです。すべての回線、すべてのプロトコル、すべての対象サイトで、現在のネットワーク上で同じ結果が得られるとは限りません。サブスクリプション、クライアントの互換性、回線経路、ルール分岐、DNSを分けて判断することで、問題の本当の原因を素早く特定できます。