このページは調べ物用の手引きで、初期設定の手順ではありません。はじめて設定する場合は、まず使い方ガイドをご覧ください。登録からサブスクリプションの取得、各プラットフォームへのインポートまで一歩ずつ進めれば接続できます。本ページで扱うのは、接続できたあとにも起こるトラブルです。症状別に九つの章へ分け、各章でまず切り分けの順序、次に自己診断の手順、最後にどういう場合にサポートへ連絡すべきかを説明します。
用語に不安がある場合は、VPN 用語のクイックリファレンスでサブスクリプション、ノード、プロトコル、分流の各用語を解説しています。先に読んでおくと、本ページはずっと読みやすくなります。料金とプランの区分は料金プランページにまとめてあり、本ページでは重複して掲載しません。二か所で数字が食い違うのを避けるためです。
01 · 切り分け
まず問題がどの層にあるかを見極める
接続の失敗は、原因が一つだけということはほとんどありません。問題が起きうる箇所を三つの層に分けると、切り分けがぐっと速くなります。第一層は端末そのもの——クライアントの設定、システム時刻、ファイアウォール、省電力ポリシー。第二層はローカルネットワークの出口——家庭のブロードバンド、社内ネットワーク、公共 Wi-Fi によるプロトコルとポートの制限。第三層が回線とアカウント——回線の混雑、サブスクリプションの期限切れ、通信量の使い切りです。三層では対処の仕方がまったく違うので、まず層を特定してから解決策を考えます。
順番は努力より大事です。つながらないからといって、すぐクライアントを再インストールする人がいますが、それでは画面に出ていた最も重要なメッセージを見失ってしまいます。再インストールが効くのは設定ファイルが本当に壊れているときだけで、それ以外では切り分けの時間をゼロに戻すだけです。
もう一点、三つの層は互いに影響し合います。端末の性能が足りないと回線が「遅い」ように見え、ローカル DNS の設定ミスは「つながらない」と「つながるが開かない」を同時に引き起こします。そこで各章の末尾には「どういう場合に一つ前の層へ戻るか」を必ず書いています。一章だけで決着をつける必要はありません。
30秒でできる3つの確認
道具はいりません。3つの動作だけで、原因の範囲はかなり絞れます。
- クライアントを切り、普通のWebページを直接開いてみる。開けないならローカルネットワーク自体が切れています。まずネットワークを直しましょう。クライアントの中に原因を探すのは後回しです。
- 端末とネットワークはそのままに、別の回線へ切り替えて再接続する。つながれば単一の回線の問題です。ノード回線から同じ地域の別タイプの予備回線を選んでください。
- 別の端末に変える、あるいは同じ端末を別のネットワークにつなぐ。端末を変えてつながれば、原因は元の端末のローカル設定です。ネットワークを変えてつながれば、原因は元のネットワークの出口ポリシーです。
| 観察された結果 | 意味 | 次の一手 |
|---|---|---|
| ローカルのWebページも開けない | ローカルネットワーク自体が不通 | まずローカルネットワークを復旧 |
| 回線を変えるとつながる | 特定の回線の異常または混雑 | 同じ地域の予備回線に切り替える |
| 端末を変えるとつながる | 元の端末の設定またはシステムポリシーに問題 | 「まったくつながらない」と「アプリがプロキシを通らない」を参照 |
| ネットワークを変えるとつながる | 元のネットワークがプロトコルやポートを制限している | 「まったくつながらない」の出口の節を参照 |
| 接続済みなのにWebページが開けない | トンネルは確立済みで、名前解決か分流で止まっている | 「つながるが開かない」を参照 |
| 決まった時間帯だけ遅くなる | 国際出口の混雑の時間的な傾向が関係している | 「夜間の混雑による重さ」を参照 |
現象を記録する。慌てて再インストールしない
サポートに連絡するとき、最も価値があるのは「つながらない」の一言ではなく、次の項目です。前もって記録しておけば、最終的に誰かに助けを求めることになっても、やり取りを一往復減らせます。
- 問題が起きた時刻とタイムゾーン、特定の時間帯に集中しているか
- プラットフォームと OS のバージョン(Windows / macOS / iOS / Android / Linux)
- クライアント画面に出たメッセージの原文(スクリーンショットまたは一字一句の書き写し)
- そのとき選択していた回線名と回線タイプ
- ルーター上で使用しているか、ルーター配下に何台つないでいるか
- 問題の前に変更したこと:DNS を変えた、セキュリティソフトを入れた、分流モードを切り替えた など
最終章へ直接飛んでよいケース
章ごとに追わなくてよいケースは二つあります。一つは、パネル上でサブスクリプションが期限切れ、または通信量を使い切っている場合です。これはアカウントの問題なので「アカウントとサポート」を直接ご覧ください。もう一つは、同じアカウントを複数の端末で同時に使っていてまったく同じ現象が出ており、ネットワークを変えても回線を変えても改善しない場合です。これは通常アカウント側のセッション状態の問題で、試行を続けるよりサポートへ連絡したほうが早く解決します。それ以外の症状は、章の順番どおりに一通り確認することをおすすめします。多くの現象は同じ原因の現れ方が違うだけだからです。
02 · 接続の確立
まったくつながらない
クライアントで接続を押してもずっと読み込み中のまま、エラーが出る、あるいはつながった直後に切れる——いずれもこのカテゴリです。まずクライアントのメッセージがどの種類かに注目してください。4種類では対処の道筋がまったく違います。
まず「つながらない」を4種類に分ける
ずっと読み込み中でメッセージなし
多くはハンドシェイク段階で止まっています。ローカルネットワークから回線のポートに届かないか、セキュリティソフトに遮断されています。
明確なエラーで、認証の文字を含む
リクエストはサーバーに届いています。問題はアカウントの状態かログイン情報です。
つながって数秒で切れる
接続は確立したものの中断されています。中間装置にプロトコルを識別された場合や、システム時刻のずれで証明書の検証に失敗した場合によく起こります。
クライアントが起動しない、または強制終了する
ネットワークとは無関係です。まず OS のバージョンとインストールの完全性を確認します。
アカウントと通信量
ユーザーパネルにログインし、二点を確認します。サブスクリプションが有効期間内か、通信量に残りがあるかです。月額サブスクリプションの通信量は開始日を基準に毎月リセットされ、暦月ではありません。通信量パックは使い切るまで有効で、期限はなく、月の切り替えでも消えません。パネルには二種類の残量がそれぞれ表示されます。表示を正としてください。
パネルでサブスクリプションが有効、通信量も十分なのに、クライアントが認証失敗と表示する場合は、いったんログアウトしてから再ログインし、クライアントにアカウント情報を再取得させてください。それでも失敗するならサポートへご連絡ください。通信量パックと月額サブスクリプションのどちらが得かは、通信量パックと月額プランの選び方で使用量から試算する方法を解説しています。
システム時刻
暗号化接続は証明書の検証に依存しており、その最初の関門が時刻です。システム時刻が実際の時刻と数分以上ずれているとハンドシェイクに失敗し、そのメッセージは「ネットワークが不通」とよく似ているため誤判断しやすくなります。Windows、macOS、iOS、Android にはいずれも自動時刻合わせの設定があります。オンにしてから、手動で一度同期してください。
# Linux:時刻・タイムゾーン・同期状態を確認
timedatectl status
# 自動時刻合わせを有効にし、すぐ一度同期する
sudo timedatectl set-ntp true
ローカルネットワークの出口
社内ネットワーク、学内ネットワーク、一部のホテルや公共 Wi-Fi は UDP や常用外のポートを制限します。見分け方は簡単です。同じ端末を別のネットワークに切り替えて、もう一度接続してみてください。元のネットワークではつながらず、別のネットワークではつながるなら、原因は元のネットワークの出口ポリシーです。この場合はクライアントで転送プロトコルを切り替え、UDP 系から TCP 系にするか、より一般的なポートに変えてみてください。
ファイアウォールとセキュリティソフト
デスクトップのセキュリティソフト、OS 標準のファイアウォール、そして一部の「ネットワーク最適化」ツールは仮想ネットワークアダプターを遮断します。症状は、クライアントは接続済みと表示するのに OS に仮想アダプターが追加されない、あるいは接続が一瞬で切られるというものです。対処法は、クライアントを許可リストに追加し、仮想アダプターの作成と DNS 設定の変更を許可することです。切り分け中はサードパーティ製のセキュリティソフトを一時的に無効にして比較テストし、終わったらすぐ元に戻してください。
ルーターと複数端末
ルーター上で設定する場合、クライアントは関与しません。問題は通常、ルーターのファームウェア、時刻同期、ルールファイルの互換性にあります。順に確認します。ルーター自体が正常にインターネットへ接続できるか、ルーターの時刻が同期されているか、サブスクリプションからルールを正常に取得できたか、ルールの形式がファームウェアと一致しているか。4項目すべて問題なくてもつながらない場合は、ルーターの型番とファームウェアの種類を控えて、サポートへ連絡する際に添えてください。
| 画面のメッセージ(要旨) | 通常の意味 | まず行うこと |
|---|---|---|
| 接続タイムアウト / 応答なし | 回線のポートに届いていない | 回線を変える、ネットワークを変える、プロトコルを切り替える |
| 認証失敗 / 資格情報が無効 | アカウントの状態またはログイン情報の問題 | パネルで有効期間を確認し、再ログイン |
| 証明書の検証に失敗 | システム時刻のずれ、または中間装置による遮断 | 自動時刻合わせをオンにし、手動で同期 |
| 接続直後に切断される | プロトコルの識別、または仮想アダプターの遮断 | プロトコルを切り替え、セキュリティソフトの許可リストを確認 |
| 仮想ネットワークアダプターを作成できない | 権限またはドライバーの問題 | 管理者権限で実行し、仮想アダプターを再インストール |
03 · 名前解決と分流
つながるのにページが開かない
クライアントは接続済みと表示され、出口地域も切り替わっているのに、ブラウザはずっと読み込み中のまま、あるいは一部のサイトしか開かない。この種の問題に共通するのは、トンネルはすでに確立していて、止まっているのはトンネルの上での名前解決と分流だという点です。
まず3つの現れ方を分ける
どのサイトも開けない
DNS の名前解決がトンネルを通っていないか、仮想アダプターが通信を引き受けていません。
一部のサイトだけ開けない
分流ルールが対象ドメインを直結と判定し、その直結経路自体が不通になっています。
ページは開くがスタイルが欠ける
MTU の不一致で大きなパケットが破棄されています。骨組みは出るのに画像やスタイルが読み込めない形で現れます。
DNS リークと DNS 失敗の違い
DNS リークとは、問い合わせがトンネルを通らずローカル DNS が露出することです。DNS 失敗とは、問い合わせがそもそも結果を返さないことです。どちらも「ページが開かない」形で現れますが、対処は異なります。リークはクライアントの DNS 引き受け設定を変更し、失敗はまずシステム DNS に到達できるかを確認します。
# Windows:DNS 設定を確認し、キャッシュをクリア
ipconfig /all
ipconfig /flushdns
# macOS:DNS キャッシュをクリア
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
# Linux(systemd-resolved):状態を確認し、キャッシュをクリア
resolvectl status
sudo resolvectl flush-caches
# 共通:あるドメインがどのアドレスに解決されるか問い合わせる
nslookup example.com
nslookup が返すのがローカル回線事業者やルーターのアドレスなのに、クライアント側で DNS をトンネル経由にする設定が有効になっている場合、問い合わせはシステムに迂回されています。対処法は、クライアントで DNS をトンネル経由に設定するか、1.1.1.1 や 8.8.8.8 のような利用可能なパブリック DNS を手動で指定し、変更後にシステムのキャッシュを一度クリアすることです。
分流モードとルール
ルールモードでは、クライアントはドメインリストに従ってプロキシ経由か直結かを決めます。対象サイトがリストになければ、あるいはリストが古ければ直結になります。見分け方は、モードを一時的にグローバルへ切り替えることです。グローバルなら開けてルールでは開けないなら、原因はルールにあります。対処はルールを更新するか、そのドメインをカスタムルールに追加することです。
分流ルールには見落としやすい境界がもう一つあります。同じドメインが「直結リスト」と「プロキシリスト」の両方に該当することがあり、最終結果はクライアントの優先順位で決まります。ルールは多ければよいというものではなく、衝突するルールは切り分けを難しくします。ルールはできるだけ簡潔に保ち、本当に必要な項目だけを足してください。
MTU と大きなパケットの破棄
トンネルはヘッダーを余分にカプセル化するため、実際に使える最大転送単位は物理リンクより小さくなります。MTU の設定が大きすぎると、小さなリクエストは通るのに大きな応答が破棄され、ページの骨組みは出るのに画像やスタイルが読み込めない、あるいはログイン操作がずっと読み込み中のまま、といった形で現れます。MTU を一段階小さくして試すのが、最も低コストな検証方法です。
| 現象 | 考えられる原因 | 対処 |
|---|---|---|
| 全サイト開けないが、IP 直指定なら開ける | DNS がトンネルを通っていない | トンネル内 DNS を有効にし、システムキャッシュをクリア |
| ごく一部のサイトだけ開けない | 分流ルールが直結と判定している | グローバルに切り替えて比較し、カスタムルールを追加 |
| 骨組みは出るが画像が欠ける | MTU が大きすぎる | MTU を一段階下げる |
| サイトがローカル版に転送される | 分流または DNS の帰属判定 | 出口地域を変え、ルールを確認 |
| 証明書エラーが出る | システム時刻または中間装置 | 時刻を合わせ、ネットワークを変える |
04 · スループット
速度が遅い
「遅い」は最も数値化しにくい種類です。まず基準を作ります。プロキシなしでローカルネットワークの実速度がいくらか、プロキシをかけるとどれだけ落ちるか。基準がなければ「遅い」は主観的な感覚にすぎず、回線を十本変えても改善しないことがあります。
まず基準を測り、それから最適化を考える
クライアントを切った状態で、同じ端末・同じ場所でローカル帯域を一度測り、記録します。次にプロキシに接続し、同じ測定方法でもう一度測ります。二つの差が、プロキシ経路による損失です。ローカル自体の帯域がもともと低ければ、回線を変えても大きな改善は見込めません。ボトルネックは回線ではないからです。
速度測定そのものにもコツがあります。測定サーバーの位置は結果に大きく影響します。測定ノードが国内にあり、プロキシの出口が海外にあると、出てくる数字は「国内から国内」を反映したもので、実際の国際区間の速度ではありません。より実感に近い方法は、普段使うサイトを開いて、初回表示までの時間、画像の読み込み、動画の再生開始の3点を見ることです。
シングルスレッドとマルチスレッド
シングルスレッドのダウンロードは単一接続の品質を、マルチスレッドは総帯域を反映します。シングルは遅いがマルチは正常なら、回線が単一接続に対する制限を強くかけているということです。並列の複数タスクには向きますが、大容量ファイルのシングルスレッドダウンロードには向きません。マルチも遅いなら、ボトルネックはリンクの総帯域かローカルの出口です。判断するときは、同じファイルを同じ時間帯にそれぞれ測って初めて比較できます。
回線タイプの影響
直結回線は経路が最短ですが、経由する公衆網のノードが多く、夜間は国際出口の混雑の影響を受けやすくなります。中継回線は途中に1ホップ増えますが、経路をより制御できます。IEPL 専用線は独立したチャネルを通るため、遅延とジッターが安定しており、その分コストも高くなります。同じ地域に3タイプの回線が併存することもあり、速度の出方は大きく違うので、一本ずつ試す価値があります。ノード回線ページには地域ごとに各回線のタイプが載っているので、選ぶときの参考にしてください。
端末と Wi-Fi
暗号化と復号には CPU を使います。古い端末、省電力モードのノート PC、バックグラウンドで動き続けるプログラムは、実際のスループットを回線の能力より低くします。見分け方は、より高性能な端末に同じ回線で切り替えて比較することです。Wi-Fi については、2.4GHz 帯の実効スループットは 5GHz よりはるかに低く、壁を隔てるとさらに落ちます。有線接続が最も安定した比較対象です。
特定のサイトだけ遅い
特定のサイトだけ遅く、ほかは正常なら、原因は回線ではない可能性が高いです。CDN の振り分けは出口 IP によってノードを割り当てるため、出口地域が遠ければ割り当てられる CDN ノードも遠くなります。出口地域を対象サイトのサービス地域に近いものへ変えるほうが、回線を変えるより効くことがよくあります。100+ の国・地域、220+ の回線という規模なら、ほとんどの対象サービスに対して地理的により近い出口が見つかります。
| 場面 | 考えられる原因 | 対応 |
|---|---|---|
| 全体的に遅く、ローカルの速度測定も低い | ローカル帯域が不足 | まずローカルネットワークを解決 |
| シングルは遅いがマルチは正常 | 単一接続の速度制限 | マルチスレッド対応のダウンロードツールに変更 |
| 日中は正常、夜は遅い | 国際出口の混雑 | 「夜間の混雑による重さ」を参照 |
| 特定のサイトだけ遅い | CDN の割り当てが遠い | より近い出口地域に変更 |
| 端末を変えると明らかに速い | 元の端末の性能またはバックグラウンドの負荷 | バックグラウンドのプログラムを終了し、省電力モードを確認 |
05 · 時間帯
夜間の混雑による重さ
問題が決まった時間帯にだけ起きるなら——日中は正常で夜だけ重いなら——それはランダムな故障ではなく、規則性のある混雑です。家庭用ブロードバンドと国際出口は夕方から夜にかけて負荷が最も高くなり、国際区間の遅延とパケットロスが増えます。直結系の回線が最も影響を受けます。
夜間に顕著になる理由
国際区間は国際出口を経由し、出口の帯域は共有資源です。夜間は家庭用ブロードバンドの利用者が同時に最も多くなり、出口の待ち行列遅延が増え、パケットロス率も上がります。パケットロスが転送に与える影響は累積的です。1回のロスが再送と輻輳ウィンドウの縮小を招き、実効スループットの落ち込みはロス率の数値そのものよりはるかに大きくなります。夜間に「ほんの少し重いだけ」が体感では「動画がずっと読み込み中」になるのは、こういう理由です。
まず時間の規則性を確認する
数日続けて、同じ回線・同じ時間帯で記録します。接続は正常か、ページを開くのに何秒かかるか、動画が何回バッファリングしたか。3日分あれば傾向は見えます。重さが時間と無関係なら「速度が遅い」の章に戻ってください。重さが特定の回線だけで起きるなら、原因は回線自体なので、回線を変えれば済みます。
回線タイプの選び方
夜間の挙動は回線タイプと強く関係します。直結回線は公衆網を通るため、混雑時はジッターが目立ちます。中継回線は中間ノードで収束させている分、安定性が少し高くなります。IEPL 専用線は独立したチャネルを通るため、公衆網の混雑の影響を最も受けにくくなります。予算が許すなら、夜間の時間帯に専用線系の回線へ切り替えるのが最も直接的な改善方法です。
出口地域の選び方
同じサイトでも出口地域によって応答は大きく変わります。アジア方向の回線は、夜間の遅延が太平洋横断方向より低いのが一般的です。対象サービスが複数の地域にノードを持つなら、地理的により近い出口を優先してください。対象サービスが一つの地域にしかノードを持たないなら、その地域の中で回線タイプを選ぶしかありません。
使い方の調整
- 大容量ファイルのダウンロードや OS のアップデートは、ピーク外の時間帯に回す
- 動画の画質は自動から固定に変え、ビットレートの切り替えによる度重なるバッファリングを避ける
- 同時視聴する端末が増えるほど、一台あたりの帯域は減る——台数無制限は総帯域無制限ではない
- ゲーム系のアプリはピーク帯域よりも遅延とジッターを見る
ライブ配信とスポーツ観戦の場面
スポーツのライブ配信は遅延と同時接続に敏感です。試合開始10分前は接続確立のピークなので、余裕をもって接続し、再生ページも先に開いておくほうが、開始後に慌てて回線を切り替えるより安定します。大会期間中の回線選びの考え方はスポーツライブ向け回線の比較でより細かく解説しています。
| 時間帯 | 現象 | おすすめ |
|---|---|---|
| 日中 | 正常 | 現在の回線を維持 |
| 夕方 | ページ表示が遅くなる | 中継または専用線系の回線に変更 |
| 夜間 | 動画が頻繁にバッファリングする | 画質を固定し、複数端末での同時高画質再生を避ける |
| 深夜 | 正常に戻る | 出口の混雑によるもので、端末の故障ではない |
06 · 安定性
頻繁な切断とモバイルのバックグラウンド切断
切断には二種類あります。接続が能動的に切られる場合と、接続は残っているのにアプリケーション層で通信がない場合です。前者はクライアントが切断・再接続と表示し、後者はつながったままに見えて実際には何も通っていません。対処はまったく異なります。
一定間隔で切れる
決まった時間ごとに切れる場合は、ハートビートのタイムアウトかアイドルタイムアウトが関係していることが多いです。中間装置は長時間通信のないセッションのエントリを消去します。クライアントは接続が残っていると思っていても、装置側ではすでにそのセッションを忘れている状態です。対処法は、クライアントでハートビート間隔を有効にするか短くすること、あるいは軽いバックグラウンド通信を流し続けることです。
ランダムな切断
規則性のない切断は、多くがリンクの揺らぎです。見分け方は、切断された瞬間にクライアントの状態を見ることです。「接続済みだが通信なし」ならリンクの問題、「切断済み」ならローカルネットワークか仮想アダプターの問題です。Wi-Fi の電波が弱い、ルーターの負荷が高い、回線事業者側の揺らぎなどがこの類を引き起こします。
デスクトップのスリープ復帰
ノート PC を閉じてスリープさせ、復帰したあと、仮想アダプターが通信を引き受け直しておらず、クライアントは接続済みと表示するのに実際には通じないことがあります。切断して再接続すれば回復します。復帰のたびに手動で再接続が必要なら、クライアントの自動起動とネットワーク変更時の自動再接続の設定を確認してください。
ルーター配下のセッションテーブル
ルーターは NAT のセッションテーブルを維持する必要があり、テーブルが満杯になると新しい接続を確立できなくなります。症状は「ネットワークは生きているのに新しいページが開けない」です。低価格帯のルーターはセッションテーブルの容量が限られており、端末が増え、同時接続が増えると上限に達しやすくなります。ルーターの再起動で一時的に緩和できますが、長期的な解決策は同時接続する端末を減らすか、メモリのより大きいルーターに替えることです。
モバイルのバックグラウンド切断
iOS も Android も、バックグラウンドアプリのネットワーク活動を制限します。バックグラウンドに回ってしばらくすると、OS が VPN 構成を回収したりクライアントのプロセスを一時停止したりして、フォアグラウンドに戻ると再接続中と表示されます。これは OS のポリシーであり、回線の故障ではありません。
- iOS:VPN 構成のオンデマンド接続が有効か確認する。該当クライアントの低電力モードの制限を外す。バックグラウンド App の更新を許可する。
- Android:バッテリー最適化でクライアントを「制限なし」に設定する。メーカー独自の省電力ポリシーによる該当アプリの終了を無効にする。バックグラウンドでの動作を許可する。
- 共通:「バックグラウンド整理」の操作でクライアントを閉じないこと。多くの OS では VPN 構成ごと停止してしまいます。
| プラットフォーム | よくある原因 | 対処 |
|---|---|---|
| iOS | オンデマンド接続が未設定、低電力モード | オンデマンド接続を有効にし、低電力の制限を解除 |
| Android | バッテリー最適化によるバックグラウンド終了 | 「制限なし」に設定し、バックグラウンド動作を許可 |
| Windows | スリープ復帰後に仮想アダプターが引き継がない | 切断して再接続、自動再接続を確認 |
| macOS | ネットワーク位置の切り替え | ネットワークサービスの順序を確認 |
| Linux | ネットワークマネージャーがルートを掌握 | ルーティングテーブルと DNS 設定を確認 |
07 · 設定の取得
サブスクリプション更新失敗
サブスクリプションの更新とは、クライアントがサーバーから設定ファイルを取得することです。失敗の原因は主に三つの段階に集中します。取得時にプロキシを通っていない、サブスクリプション URL が無効になっている、クライアントが古い設定をキャッシュしている。この順に確認すれば、ほとんどの場合は一度で特定できます。
まず取得経路を確認する
多くのクライアントはサブスクリプション更新時にプロキシを通らず、直結で取得しに行きます。サブスクリプション URL が現在のネットワークから到達できない場合、更新は失敗します。対処法は、まずクライアントをグローバルモードに切り替えるか、更新リクエストを確立済みのトンネル経由にしてから更新を押すことです。更新に成功したらルールモードに戻します。
サブスクリプション URL と資格情報
サブスクリプション URL には識別情報が含まれており、パスワードと同じ扱いです。URL がリセットされたり期限切れになったりすると、更新はエラーを返します。ユーザーパネルでサブスクリプション URL を取得し直し、クライアントの古い URL を置き換えてください。
# 例:サブスクリプション URL の形式(サンプル値であり、実在の URL ではありません)
https://example.com/sub?token=YOUR_TOKEN
上記の URL は形式を示すためのものです。実際のサブスクリプション URL はユーザーパネルから取得してください。ネット上に出回っているサンプルをコピーしたり、自分の URL を公開の場に貼ったりしないでください。
クライアントのキャッシュ
更新に成功したのに回線リストが変わらない場合は、通常クライアントがキャッシュを使っています。キャッシュを消去するか、サブスクリプションを削除して再インポートすれば強制的に更新できます。一部のクライアントでは「すべて更新」を手動で押さないとルールを再取得しません。ノードだけ更新しても分流ルールは更新されません。
ルーター上での更新
ルーター環境で更新が失敗する場合、よくある原因は三つです。ルーターの時刻が同期されておらず証明書の検証に失敗する、DNS がサブスクリプションのドメインを解決できない、ストレージ不足で書き込みに失敗する。順に切り分けます。まず時刻合わせ、次に DNS の変更、最後にストレージの確認です。
サブスクリプション形式とクライアントの互換性
同じサブスクリプション URL でも、クライアントによって必要な形式が異なることがあります。形式が合わない場合、クライアントは解析失敗を表示するか、インポートは成功しても回線リストが空になります。その場合はまずパネルでサブスクリプションの形式オプションを確認し、クライアント側で対応するインポート方法を選んでください。形式が判別できないときは、クライアントが既定で推奨するものを優先してください。
| 現象 | 原因 | 対処 |
|---|---|---|
| 更新がずっと読み込み中のまま | 取得リクエストがプロキシを通っていない | グローバルに切り替えてから更新 |
| URL が無効と表示される | サブスクリプション URL がリセットされた | パネルで再取得 |
| 更新は成功したがリストが変わらない | クライアントのキャッシュ | キャッシュを消去するか再インポート |
| インポートは成功したが回線が空 | サブスクリプション形式の不一致 | 別のインポート形式に変更 |
| ルーターでの更新に失敗 | 時刻、DNS、またはストレージ | 時刻合わせ、DNS 変更、空き容量の確保 |
08 · 分流とトンネルの引き受け
特定のアプリがプロキシを通らない
ブラウザは正常なのに、あるアプリだけつながらない場合、トンネル自体は通っています。問題はそのアプリの通信が引き受けられていないか、引き受けたあとの名前解決に失敗していることです。
まずグローバルで比較する
クライアントをグローバルモードに切り替えて、同じアプリを開いてみてください。グローバルで正常なら、ルールがそのアプリのドメインをカバーしていません。グローバルでも不正常なら、アプリが仮想アダプターを通っていないか、独自のネットワーク実装を持っています。
システムプロキシと仮想アダプター
システムプロキシは、システムのプロキシ設定を読むアプリにしか効きません。多くのアプリ——特にゲーム、一部のデスクトップクライアント、コマンドラインツール——はシステムプロキシを読まず、仮想アダプターだけを通ります。こうした通信を引き受けるには、クライアントで TUN モードまたは仮想アダプターモードを有効にする必要があります。
アプリ独自のネットワーク実装
- 独自 DNS を持つアプリ:システム DNS を迂回し、固定アドレスへ直接問い合わせるため、分流ルールが誤判定することがあります。
- IP をハードコードしたアプリ:ドメイン名の解決を経ないため、ドメインで書かれたルールに該当しません。
- QUIC を使うアプリ:UDP を使うため、一部のネットワークで制限され、接続は確立するのに読み込めない形で現れます。
- 独自プロトコルを使うクライアント:個別にプロキシを設定するか、仮想アダプター経由を強制する必要があります。
アプリ別プロキシ
一部のクライアントはアプリ別の分流に対応しており、どのアプリをプロキシ経由にし、どれを直結にするかを指定できます。ルールを逆に書くと「通すべきものが通らず、直結すべきものが直結しない」状態になります。リスト内で対象アプリがプロキシ側にあるか確認し、変更後はアプリを再起動してから試してください。
コマンドラインツールと環境変数
コマンドラインツールは通常、環境変数しか見ず、システムプロキシを読みません。ターミナルで一度設定してから、ネットワークが必要なコマンドを実行してください。
# ポートはクライアントが実際に待ち受けているものに合わせる
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
# 出口の確認:戻り値は現在の回線の出口地域と一致するはず
curl -s https://example.com/ip
本当にプロキシを通っているか確認する
アプリ内で出口アドレスを表示するページを開き、返ってきたアドレスが回線の出口かどうかを見ます。この一手間で、通信が引き受けられているかどうかが確認できます。より詳しい自己診断の方法は接続後に有効かどうかを確認する方法にまとめています。
| アプリの種類 | よくある原因 | 対処 |
|---|---|---|
| ブラウザ | ルールが未カバー | ルールを追加するかグローバルに切り替え |
| デスクトップのゲームクライアント | システムプロキシを読まない | 仮想アダプターモードを有効化 |
| コマンドラインツール | 環境変数のみ参照 | プロキシの環境変数を設定 |
| モバイルアプリ | VPN 構成を通っていない | アプリ別プロキシのリストを確認 |
| 動画クライアント | QUIC が制限されている | そのアプリの QUIC を無効化 |
09 · アカウントと人的サポート
アカウント、端末、サポート依頼の出し方
ここまでの八章は技術的なトラブルを扱ってきました。この章ではアカウント面の問題と、実際に人による対応が必要なときの進め方を扱います。
台数無制限の意味
本サービスのプランは台数無制限で、端末数による課金はありません。同じアカウントを Windows、macOS、iOS、Android、Linux に同時にインストールでき、二台目のために追加購入する必要はありません。台数無制限とは端末数のことであり、総帯域が無制限という意味ではありません。同時にオンラインの端末が増えるほど、一台あたりの帯域は減ります。
ルーターと共有
ルーター上で設定する場合、ルーターが一台の端末として数えられ、その配下のすべての端末がこの接続を共有します。家庭では最も手間のかからない方法ですが、ルーターの性能に注意が必要です。低価格帯のルーターは暗号化のスループットが限られており、端末が増えるとボトルネックになりやすくなります。見分け方は簡単です。クライアントを PC に直接インストールして比較し、直結のほうが明らかに速ければ、ボトルネックはルーターです。
端末数に関するメッセージの読み方
本サービスは台数無制限のため、通常は端末数を理由に拒否されることはありません。特定のクライアントで端末数に関するメッセージが出た場合は、いったんログアウトして再ログインし、クライアントにアカウント情報を再取得させてください。それでもメッセージが出る場合は、スクリーンショットを添えてサポートへ連絡し、メッセージが出たクライアントと時刻を明記してください。
通信量と有効期限
月額サブスクリプションの通信量は開始日を基準に毎月リセットされ、暦月ではありません。途中でプランをアップグレードした場合、差額は残り日数に按分されます。通信量パックは使い切るまで有効で、期限はなく、月の切り替えの影響も受けません。二種類の枠はパネルにそれぞれ表示されます。更新前に、どちらの枠が先に尽きるのかを確認してください。
アカウント情報の管理
登録に必要なのはユーザー名とパスワードだけで、メールアドレスは不要です。つまりアカウント情報はこの二つだけです。裏を返せば、メールによる復旧手続きは使えないということでもあるので、パスワードはご自身で厳重に管理し、サブスクリプション URL と一緒に公開の場に置かないでください。プラン区分と通信量パックの対応は料金プランをご覧ください。支払い方法は Alipay / WeChat Pay / USDT に対応しています。
返金
30日間の理由を問わない返金に対応しています。申請窓口と必要情報は返金ポリシーをご覧ください。申し込み時に注文日時とプラン名を添えていただくと、確認がスムーズです。
サポートに連絡すべきケース
- 異なる地域の回線を少なくとも3本試し、ネットワークも変え、プロトコルも切り替えたのに、まったくつながらない
- パネルではサブスクリプションが有効で通信量も十分なのに、クライアントが認証失敗を繰り返す
- サブスクリプションの更新が複数のネットワークで失敗する
- 特定の回線が数日続けて決まった時間帯に使えない
- アカウントに関する課金、返金、プラン変更の相談
サポートに添える情報
情報が揃った一件の連絡なら、通常は一度で問題を特定できます。次の項目を添えてください。
- 問題が起きた時刻とタイムゾーン
- プラットフォームと OS のバージョン
- クライアント画面のメッセージ原文(スクリーンショットまたはテキスト)
- そのとき選択していた回線名と回線タイプ
- すでに行った切り分け作業とその結果
- ルーター上で使用しているか、配下に何台つないでいるか
問題の現象:接続後、ブラウザでページが開けない。クライアントは接続済みと表示
発生日時:2026-10-20 21:30 (UTC+8)
プラットフォーム:Windows / クライアントの現行バージョン
現在の回線:日本 · 東京(中継)
確認済み:グローバルモードに切り替えても効果なし。DNS を変更しても失敗。
シンガポール回線に変えると正常に開ける
補足:ルーター配下に三台の端末
サブスクリプション URL の全体、パスワード、その他の資格情報は添えないでください。アカウントについて説明が必要な場合は、ユーザー名だけで十分です。
送る前に一度確認する
多くの問題はヘルプセンターに既に答えがあります。特に課金やプランに関するものがそうです。確認したうえで連絡すれば、問題の説明もより正確になり、同じ問題が二重に並ぶのも避けられます。