VPN トラブル診断ガイド

01

はじめに：診断の流れと準備するもの

クイックスタートのページは、ゼロから接続できるまでの一直線の手順を扱っています。登録、購読の取得、クライアントへの読み込み、疎通確認という流れです。トラブルシューティングは一直線ではありません。同じ「ページが開かない」でも、名前解決の失敗、振り分けルールが直結に戻している、システムプロキシが実際には効いていない、回線そのものに問題がある、といった原因が考えられます。毎回インストール手順からやり直すと、すでに正常な部分に時間を費やすことになります。

このガイドは症状ごとに構成しています。各章は実際に目にする現象に対応し、まず判断フローを示して、手を動かす前に原因を一、二個に絞り込みます。そのうえで具体的な自己確認の手順と対処法を説明します。9つの章に順番はありません。上の目次から該当する章へ直接移動してください。

• 02まったくつながらないクライアントに通信がまったくない
• 03接続できるのにページが開かないトンネルは通るが読み込みが止まる
• 04速度低下と夜間の混雑動画が止まる、ダウンロードが進まない
• 05頻繁な切断接続してすぐ切れる
• 06購読更新の失敗回線リストが空、または取得できない
• 07アプリだけ通信できないブラウザは開くがアプリはだめ
• 08モバイルのバックグラウンド切断画面ロック後に接続が消える
• 09問い合わせに添付するもの必須の6項目

クイックスタートとの役割分担

クライアントのインストールがまだ、購読もまだ読み込んでいない場合は、先にクイックスタートの流れを済ませてください。登録、購読の取得、読み込み、確認の4ステップです。その流れを終えても問題が残る場合に、ここへ戻ってきてください。逆に、すでに普通に使えていて、たまに特定のサイトだけ開けないという場合は、インストールをやり直す必要はありません。該当する症状の章を直接読んでください。

共通の診断手順：現象を特定してから層を絞る

どの症状でも、診断の順序は3ステップです。1つ目は、現象を再現できるレベルまで具体的にすること。「ときどき遅い」は現象になりません。「夜8時から10時まで、特定の動画サイトだけ読み込みが止まり、他のサイトは正常」なら現象です。再現できる現象でなければ、原因は特定できません。

2つ目は、問題がどの層にあるかを見極めること。海外アクセスの経路は、おおまかに5つの層に分けられます。アプリ本体、OSのプロキシ設定、クライアントと振り分けルール、ローカルネットワークの出口、国際回線です。各層にはそれぞれ観察方法があり、第3章から第8章はほぼこの層分けに沿って進みます。

3つ目は、一度に1つの変数だけを変えること。変えたらすぐ同じ作業で再テストし、効果を確認してから次を変えます。3つの設定を同時に変えると、どれが効いたのか分からなくなり、次に同じ問題が起きたときにも役に立ちません。

作業を始める前に集めておくもの

• クライアント名と、画面に表示されているバージョン情報
• 現在使用している回線名と回線タイプ
• エラーの原文（自分の言い換えではなく）
• OSのバージョンとネットワーク環境（家庭用回線、社内ネットワーク、公共Wi-Fi、モバイル回線）
• 問題が出ている具体的なアプリと具体的なURL
• 問題が始まった時刻、その前に設定を変更したかどうか

これらの情報は第9章でもう一度使います。問い合わせ時の必須項目でもあるので、先に用意しておくとやり取りを1往復減らせます。

3つの原則

1つ目、クライアントの再インストールを繰り返さないこと。接続の問題の多くはインストールファイルとは無関係で、再インストールは購読と設定を消すだけ、むしろ変数が1つ増えます。

2つ目、記録せずにプロトコルやポートを切り替えないこと。切り替え自体は有効な切り分け手段ですが、元の値を覚えておかないと戻せなくなります。

3つ目、本番環境で試さないこと。仕事で使う端末やアカウントは、まず別の端末で変更を検証し、問題ないと確認してから反映してください。

このガイドで使う用語

回線タイプ：IEPL 専用線、中継、直結。違いはデータが入口から出口までどう通るかにあります。第4章に一覧表があります。振り分け：どの通信を回線に通し、どれをローカル直結にするかをクライアントが決めるルール群。出口：目的のサイトにアクセスしたとき、相手側に見えるアドレスの所在地。購読：アカウントに紐づく回線リストと設定で、クライアントが定期的に取得して更新します。第6章で詳しく扱います。セッション：クライアントと回線の間に維持される接続で、切れると再構築が必要です。

用語を先に押さえておくと、以降の章の判断フローが読みやすくなります。分からない言葉が出てきたら、この節に戻って確認してください。

02

まったくつながらない：クライアントから回線までの4層切り分け

「まったくつながらない」には2種類あります。クライアントが未接続と表示する場合と、接続済みと表示されるのに通信がまったくない場合です。前者はトンネル確立の前で止まっており、後者はトンネル確立の後で止まっています。分けて考えてください。

第1層：クライアントが本当に動いているか

まずプロセスが存在し、画面が起動画面で固まっていないことを確認します。Windows ならタスクバーのトレイアイコンがクリックに反応するか、macOS ならメニューバーのアイコンを確認します。開いても真っ白だったり読み込みが続く場合は、再インストールではなく、いったん完全終了してから起動し直してください。

次に権限を見ます。macOS では初回起動時に VPN 設定の追加許可を求められ、拒否するとクライアントの画面は正常に見えるのに接続ボタンを押しても反応しません。システム設定のネットワーク項目で設定が存在するか確認してください。Windows ではインストール時に仮想ネットワークアダプタのドライバ導入に同意したかどうかが重要で、セキュリティソフトに止められているとクライアントは起動できてもトンネルを確立できません。この層の問題には共通の特徴があります。どの回線、どのプロトコルに変えても結果が同じです。

第2層：ローカルネットワークが外に出られるか

まずクライアントを切断し、通常の方法でローカルのサイトを開きます。開けないなら問題はローカルネットワークにあり、回線とは関係ありません。以降の層を見る必要はありません。

公共Wi-Fiではよく2つの状況があります。Web認証が必要なのに、認証ページがクライアントに横取りされている。あるいはネットワーク自体が一般的なポートしか通していない。前者はクライアントを切って認証を済ませてから接続し、後者は別のネットワークで確認してください。

社内ネットワークやキャンパスネットワークでは、一般的でないポートが制限されていることがあります。クライアントがポート切り替えに対応しているなら、443 に変えて試してください。通過率が最も高いポートです。

第3層：購読とノードリストが読み込まれているか

クライアントの回線リストを開きます。リストが空なら問題は購読にあり、回線ではありません。よくある原因は、購読URLの失効、アカウントの通信量の使い切り、クライアントが設定を一度も取得できていない、などです。

購読取得の切り分けは第6章で扱います。ここでは1点だけ確認してください。リストに回線があるかどうかです。回線はあるのに1本もつながらないなら第4層へ、リストが空なら第6章へ進んでください。

第4層：回線とプロトコル

別の地域の回線に変え、回線タイプも変え（たとえば中継から IEPL 専用線へ）、さらにプロトコルも変えます。3回の切り替えのうち1回でも成功すれば、単一の回線または単一のプロトコルの問題であり、アカウントやネットワークの問題ではありません。失敗した回線を記録して報告してください。

すべての回線、すべてのプロトコルで通らない場合は、第2層に戻ってローカルネットワークを再確認し、あわせてシステム時刻が正確かどうかも確認してください。時刻のずれが大きいと暗号化のハンドシェイクがそのまま失敗しますが、画面にはたいてい「接続に失敗しました」としか出ず、本当の原因は分かりません。

4層すべてを確認してもつながらない場合は、第9章の形式で現象を記録して問い合わせてください。記録には各層で何が見えたかを書き、「つながらない」だけでは伝わりません。

03

接続できるのにページが開かない：名前解決・振り分け・プロキシ

クライアントが接続済みと表示するのは、トンネルの確立に成功したというだけです。データが目的のサイトに届くまでには、名前解決、振り分けの判定、システムプロキシの転送という3つの段階があります。どれか1つが切れると、症状は「つながるのに開けない」になります。

「つながった」は何を意味するか

トンネルの確立は、クライアントと回線の間が通ったことを意味します。ただしそれは、あなたから回線までの区間だけです。回線から目的のサイトまでの区間、そして端末がリクエストをクライアントに渡す仕組みは、それぞれ独立しています。だから診断では、接続状態のランプだけを見るのではなく、リクエストの経路を区間ごとに追ってください。

名前解決の異常に現れる3つの症状

1つ目、どのサイトも開けないが、クライアント上では通信が流れている。これは多くの場合、解決リクエストが回線を通らず、ローカルネットワークから誤った結果が返されています。

2つ目、開けるサイトと開けないサイトがあり、開けないのがちょうど海外のサイトである。これは解決結果が妨害されている典型例です。

3つ目、開けるがとても遅く、毎回十数秒待たされる。これは解決がタイムアウトして予備のサーバーに切り替わっている状態です。

自己確認の方法：コマンドラインから公共の名前解決サービスに同じドメインを直接問い合わせ、2つの結果を比べます。

nslookup example.com 1.1.1.1
nslookup example.com

2つのコマンドが返すアドレスがまったく違うなら、既定の解決が返しているのは正しい結果ではありません。macOS と Linux では dig が使え、出力がすっきりします：

dig @1.1.1.1 example.com +short
dig example.com +short

対処法は、クライアントの名前解決を回線経由に設定するか、信頼できる解決サービスを手動で指定することです。変更後はクライアントを完全に終了してから起動し直してください。名前解決の設定は、すでに確立した接続には反映されません。

振り分けルールが目的のサイトを直結に戻している

振り分けルールは、どのドメインを回線に通し、どれをローカルに流すかを決めます。ルールセットの古さ、ルールモードの選択ミス、手動で追加した直結ルールのいずれかで、特定のサイトが直結に戻されます。

判断は簡単です。クライアントをグローバルモードに切り替え、同じサイトを開きます。開ければ振り分けの問題、開けなければ振り分けの問題ではありません。振り分けの問題だと分かったら、まずルールセットを更新し、次にカスタムルールの一覧に関連する項目がないか見てください。グローバルモードはあくまで切り分けの手段で、常用はルールモードをおすすめします。そうしないとローカルのサイトまで遠回りし、余計な遅延が増えます。

システムプロキシとブラウザのプロキシが食い違う

クライアントがシステムプロキシを引き受けたあと、ブラウザにプロキシ拡張機能が入っていると、拡張がシステム設定を上書きします。症状は、クライアントは接続済みなのに、ブラウザはローカルネットワークのまま通信しているというものです。

確認方法：ブラウザで現在の出口の所在地が分かるページを開き、クライアントに表示されている回線の地域と比べます。違っていればプロキシは実際には効いていません。もう1つのよくある原因は自動設定スクリプトで、スクリプトの判定ミスが目的のドメインを除外してしまいます。一時的にグローバルプロキシに変えて試せば確認できます。

判断フロー

04

速度低下と夜間の混雑：回線タイプ・輻輳・ローカルのボトルネック

「遅い」は最も誤判定しやすい現象です。少なくとも3つのまったく異なる原因があり、それぞれ対処法も異なります。

まず3種類の「遅い」を分ける

ハンドシェイクが遅い：接続を押してから接続済みになるまでに長く待たされる。トンネル確立の過程が遅いのであって帯域とは関係なく、多くは回線の入口側の応答の問題です。

最初のバイトが遅い：接続はすぐなのに、ページを開くまでに長く待たされ、内容が出始めると速い。これは遅延と名前解決の問題で、帯域の問題ではありません。

持続的なスループットが低い：ページは開けるが、動画が止まり続け、ダウンロードが進まない。これが本当の帯域の問題です。

3種類の遅さは原因がまったく違います。まずどれに当たるかを見極めてから手を動かすと、無駄な試行を大幅に減らせます。

回線タイプと向いている用途

IEPL 専用線：入口から出口まで専用の通道を通り、他の利用者と取り合いません。遅延が安定しており、リアルタイム会議、リモートデスクトップ、API 呼び出しなど揺らぎに敏感な用途に向きます。

中継：まず中継ノードに入ってから海外に出る方式で、経路が直結より短く、夜間の混雑時も直結より安定しがちです。動画や日常のブラウジングに向きます。

直結：ローカルから海外ノードへ直接つなぐ方式で、経路が最も長く、国際出口の輻輳の影響を最も受けます。遅延に敏感でない大容量ダウンロードに向きます。

夜間の混雑が起きる理由

夜8時から11時は国際出口が最も混み合う時間帯です。この時間は直結回線の揺らぎが明らかに大きくなり、中継と専用線は比較的安定します。この時間帯だけ遅く、他の時間は正常なら、ほぼ出口の輻輳と判断できます。あなたのネットワークや端末の問題ではありません。

対処は3つあります。中継または専用線に変える、大容量の処理をピーク外の時間に移す、クライアントでプロトコルを変えてみる。いずれもアカウント設定を変える必要はなく、購入済みプランの通信量にも影響しません。120+ 国 / 180+ 回線の規模であれば、同じ地域に複数の回線があるのが普通で、1本に固執するより別の回線に変えるほうが早く解決します。

ローカルのボトルネックを調べる

まず無線LANを見ます。同じ端末をLANケーブルでルーターに直結して測り、差が大きければ無線の問題です。2.4GHz 帯は夜に近所のルーターと取り合いになり、5GHz 帯は到達距離が短いので、壁1枚で速度が落ちることがあります。

次にルーターです。古いルーターは転送性能が限られており、十数台の端末をつなぐと、帯域より先に転送能力がボトルネックになります。

最後にバックグラウンドです。OSのアップデート、クラウドストレージの同期、オンラインバックアップが、気づかないうちに上りを埋め尽くします。上りが飽和すると下りも遅く見えます。各リクエストの確認応答が送り出せなくなるからです。

回線の問題ではないと断定できる条件

3つの兆候があります。端末を変えても速度が変わらない、ネットワークを変えても速度が変わらない、ピーク外の時間でも速度が変わらない。3つが同時に当てはまるなら、問題は回線ではなく、目的のサイト側かローカル端末にある可能性が高いです。

逆に、特定の端末だけ遅い、特定のネットワークだけ遅い、ピーク時間だけ遅いという場合は、上の節の順に確認してから回線の変更を検討してください。方向が合っていれば、数分で解決することも珍しくありません。

05

頻繁な切断：セッション維持・ネットワーク切り替え・省電力

切断はつながらないことより厄介です。調子が良かったり悪かったりして再現しにくいからです。ただし切断の形そのものが情報を持っています。まず形で分類すれば、範囲は半分になります。

3つの切断パターン

即断：接続して数秒で切れる。多くはプロトコルやポートが中間機器に識別され、リセットされています。

周期的な切断：数分おきに切れ、間隔がほぼ一定。多くはハートビートのタイムアウトか、クライアントと回線の間のセッション維持の失敗です。

長時間後の切断：数十分から数時間使ってから切れる。多くはネットワークの切り替え、システムのスリープ、あるいは回線側のセッション回収です。

セッション維持とハートビート

クライアントはセッションを保つため、定期的に回線へハートビートを送る必要があります。間隔が長すぎると中間機器に先に回収され、短すぎると異常な通信と判定されます。多くのクライアントには既定値があるので、むやみに変えないことをおすすめします。

クライアントにハートビート関連の設定が見える場合は、まず既定値に戻し、それでも切れるか観察してください。既定値に戻すこと自体が有効な変数管理です。変えたものを先に戻し、残ったものが本当の問題です。

ネットワーク切り替えによる再接続

ノートPCをリビングから寝室へ移動すると、無線LANが1つのアクセスポイントから別のものへ切り替わり、トンネルが再構築されます。再構築の間はすべての接続が切れ、「急に切れてすぐ戻った」ように見えます。

2.4GHz と 5GHz を同じSSIDにまとめたネットワークでは、端末が両者の間を行き来し、切り替えが多いと切断も頻繁になります。2つの帯域を別のネットワーク名に分け、端末を片方に固定すると明らかに改善します。

スマートフォンで屋内から屋外へ出て、無線LANからモバイル回線に切り替わるのも同じ種類の問題です。これは故障ではなく、ネットワーク環境が変わったのでクライアントが接続をやり直している正常な動作です。

省電力ポリシーとバックグラウンド制限

これはモバイルで最もよく起きる話で、第8章で詳しく扱います。デスクトップにも似た仕組みがあります。システムがスリープするとネットワークアダプタの電源が切れ、復帰後はトンネルの再構築が必要です。クライアントが復帰イベントを正しく処理できないと、接続済みと表示されたまま実際には通信できない状態になります。この場合は切断して再接続すれば回復します。

能動的な切断と受動的な切断を区別する

クライアントのログには通常、切断理由が残ります。能動的な切断には明確な操作の記録があります。受動的な切断はタイムアウト、リセット、あるいは何も表示されずに消える形で現れます。同じ種類のタイムアウトが繰り返し記録されるなら、ローカルネットワークの揺らぎではなくセッション維持の問題とほぼ特定できます。この一手間で、「ネットが不安定」という曖昧な判断が具体的な方向に変わります。

切断の時刻を記録する

紙でもメモでもいいので、切断のたびに時刻、そのとき何をしていたか、どの回線を使っていたかを書き留めます。3日続ければ傾向が見えてきます。一定間隔ならハートビート、位置の変化に伴うならネットワーク切り替え、時間帯に伴うなら回線の輻輳です。

この記録は問い合わせのときに非常に役立ちます。「よく切れる」の一言よりはるかに有用です。同時に、問題が解決したかどうかを自分で判断する最良の材料にもなります。

06

購読更新の失敗：URL・時刻・クライアントのキャッシュ

購読更新の失敗には2つの現れ方があります。回線リストが空になる、あるいは回線は残っているのに全部つながらない。どちらも同じことを指しています。クライアントが持っているリストが最新ではない、ということです。

購読更新は何をしているか

購読はアカウント情報から生成される回線リストです。クライアントはこのURLに定期的にリクエストを送り、最新のノードリスト、振り分けルール、設定パラメータを取得します。更新に失敗すると古いリストのまま使うことになり、古いリストの回線はすでに調整されている可能性があります。

URLの失効と権限

購読URLにはアカウントに紐づく認証情報が含まれています。パスワードを再設定した、管理画面で購読を再生成した、アカウントの状態が変わった、といった場合に古いURLは失効します。

確認方法：購読URLをブラウザで開いてみてください。内容が返ればURLは有効、エラーページが返ればURL自体に問題があります。注意として、購読URLはアカウントの認証情報と同じです。グループに送ったり、スクリーンショットに写したり、公開リポジトリに上げたりしないでください。例に載っているURLはすべてダミーです（例：https://example.com/sub?token=YOUR_TOKEN）。実際のURLは自分の端末の中だけに置いてください。

更新時のネットワーク条件

購読の更新自体にもネットワークが必要です。このときクライアントが「すべて回線経由」の状態で、しかも回線が通っていないと、更新は失敗します。つまり循環です。つながらないから更新したいのに、更新するために通信が必要で、その通信が通らない。

正しい手順は、まずクライアントを直結に切り替えるか完全に終了し、ローカルネットワークで更新を1回済ませてから、回線に接続することです。

クライアントのキャッシュと読み込み方法

クライアントによっては、読み込みに失敗しても古い設定を保持し、画面には何の異常も出ません。その場合は既存の設定を削除してから読み込み直してください。古い設定のまま更新を押すのではありません。

読み込み方法も重要です。購読URLは「リンクから読み込む」を使ってください。ノード情報を手でコピーして1つずつ追加してはいけません。手で追加したノードは購読の更新に追随せず、しばらくすると全部使えなくなります。

システム時刻のずれ

購読リクエストにはタイムスタンプが付きます。システム時刻が実際の時刻と数分以上ずれていると、サーバー側がリクエストを拒否します。ノートPCを長期間シャットダウンせずに使っている、タイムゾーンを間違って設定している、といった場合に起こります。システム時刻を自動同期に設定し、クライアントを再起動して試してください。

購読URLの安全な管理

購読URLが漏れると、他人があなたの通信量を使えてしまいます。異常な消費に気づいたら、まず管理画面で購読URLを再生成してください。古いURLは即座に失効します。

また、購読URLをブラウザのブックマークに入れて端末間で同期したり、チャットのファイル送信で自分に送ったりしないでください。便利に見えますが、認証情報をより多くの場所に複製しているだけです。アカウント登録に必要なのはユーザー名とパスワードだけで、メールアドレスは不要です。認証情報の管理はすべて自分で行う必要があるため、この点には特に注意してください。

07

特定のアプリだけ通信できない：アプリ別モードとルールの優先順位

ブラウザではページが開くのに、特定のアプリだけネットワークエラーになる。これは最もよくある「部分的な不調」です。原因はほぼ常にルールかプロキシの引き受け方であり、回線の問題ではありません。

グローバルモードとルールモード

グローバルモードではすべての通信が回線を通り、ルールモードではルール表に従って判定します。特定のアプリだけ通らないのはほとんどがルールモードで起きます。ルール表にそのアプリのドメインがないか、直結ルールに一致しているためです。

アプリ別プロキシの2つの実装

1つはクライアント側で行う方式です。クライアントがインストール済みのアプリを一覧表示し、どれを回線に通し、どれを直結にするかを選びます。クライアントに高い権限が必要で、Windows と Android は対応が比較的充実しています。

もう1つはOS側で行う方式です。仮想ネットワークアダプタとルーティングテーブルを使い、すべてのアプリが既定で通り、個別のアプリをルールで除外します。macOS と iOS はこちらです。OS側で引き受ける利点は、アプリがプロキシを意識しなくてよいこと。欠点は、「どのアプリがどの経路を通ったか」という細かい情報が診断時に見えないことです。

ルールの優先順位とよくある誤判定

ルール表は通常、上から順に照合し、最初に一致した時点で止まります。直結ルールを先頭に置くと、同じドメインを対象にした後続の回線経由ルールはすべて効かなくなります。

よくある誤判定は3つです。ドメインのサフィックスを広く書きすぎて、トップレベルドメイン全体を直結に戻してしまう。アドレス帯のルールとドメインのルールが衝突する。ルールセットが古く、目的のサイトがドメインを変えたのにルールが追随していない。

調べ方：クライアントの接続ログでそのアプリのリクエストを探し、どのルールに一致したかを見ます。ログには通常、一致したルール名が書かれているので、ルール表をさかのぼって確認してください。

アプリ独自のネットワーク判定

アプリによっては起動時にネットワーク環境のチェックを行い、通らないと通信を拒否します。システムプロキシが効いていても同じです。こうしたアプリは個別に許可するか、アプリ別リストで回線経由に設定する必要があります。

別のケースとして、アプリが独自の名前解決サービスやハードコードされたアドレスを使い、システムプロキシを迂回することもあります。この場合はクライアントのグローバルモードか、OSレベルの仮想アダプタによる引き受けしかありません。

ブラウザは開けるのにアプリは開けないよくある原因

ブラウザはシステムプロキシを使いますが、アプリはそうとは限りません。アプリによっては下位のネットワークインターフェースを直接使い、システムプロキシの設定を読みません。こうしたアプリは、仮想アダプタがすべての通信を引き受けたときだけ回線を通ります。

判断は簡単です。クライアントをグローバルモードに切り替え、アプリが回復すればシステムプロキシを読んでいないということ。それでもだめなら仮想アダプタすら使えていないので、アプリ側のネットワーク設定を確認する必要があります。

判断フロー

08

モバイルのバックグラウンド切断と端末数の上限

スマートフォンでの切断は、ほとんどが回線の問題ではなく、OSによるバックグラウンドプロセスの制限です。2つのプラットフォームで症状も対処も異なります。

iOS のバックグラウンド制限

iOS はバックグラウンドプロセスを厳しく管理します。バックグラウンドに回ると接続はOSが引き受けますが、他のアプリのバックグラウンド動作は制限されます。症状としては、画面ロックからしばらくして解除すると、ネットワークが戻るまで数秒かかります。

システム設定で、VPN 構成は「オンデマンド接続」を有効にしておく必要があります。そうしないとOSがアイドル時に自ら切断します。もう1つのよくある要因は低電力モードです。有効にするとバックグラウンド更新が後回しになり、接続の復帰が遅くなりますが、完全に切れることは通常ありません。

Android のバッテリー最適化と自動起動

Android はメーカーごとに方針の差が大きいです。既定のバッテリー最適化は画面オフ後にバックグラウンドの通信を制限し、クライアントのサービスが制限されると切断として現れます。

システム設定でクライアントをバッテリー最適化のホワイトリストに入れ、自動起動とバックグラウンド動作を許可する必要があります。メーカーによっては独自の省電力スイッチが別にあり、個別にオフにする必要があります。

もう1つ見落としやすいのが「スリープ時にモバイルデータ通信を切断する」スイッチです。これがオンだと、画面オフがしばらく続くとネットワークごと切れ、接続も当然切れます。診断ではまずこの項目を確認してください。

モバイル回線と無線LANの切り替え時の再接続

スマートフォンは移動中に基地局と無線LANを頻繁に切り替え、トンネルが繰り返し再構築されます。使わないネットワークを切っておく（自宅ならモバイルデータ通信をオフにするなど）と切り替え回数が減り、切断も減ります。

「端末数の上限」が本サービスに当てはまらない理由

他のサービスから移ってきた利用者は、つながらないとまず端末数の上限を疑いがちです。本サービスの購読は同時接続端末数の制限がなく、同じアカウントを複数の端末で同時に使えます。端末が多いからといって切断されることはありません。Windows / macOS / iOS / Android / Linux の5プラットフォームで同時に接続できます。

ですから「1台つなぐと別の1台が切れる」という現象が起きた場合、原因は端末数ではなく、次のいずれかです。

実際の原因はたいてい何か

1つ目、同じ購読を2台のクライアントが同じ識別子で同時に接続し、サーバー側が古いセッションを回収している。対処は、端末ごとに独立したクライアントインスタンスを使い、端末識別子を含む設定をそのままコピーしないことです。

2つ目、ローカルネットワークがトンネルを1本しか許していない。ルーターや公共ネットワークの一部は同時に確立できるトンネル数を制限しており、後から接続したほうが先の接続を押し出します。

3つ目、アカウントの状態異常。これはユーザーパネルで直接確認できるので、推測する必要はありません。通信量の使い切りやプランの期限切れには明確な表示が出ます。端末数とは関係ありません。

09

どんなときにサポートへ：問い合わせに添付する情報

ここまでの8章で、自分で解決できる問題のほとんどをカバーしています。残ったごく一部については、問い合わせるのが正しい選択です。ただし問い合わせの質が、そのまま対応の速さを決めます。

自分で解決すべきものと問い合わせるべきもの

問い合わせに必ず添える6項目

現象の書き方

良い書き方：「夜8時以降、特定の地域の中継回線でHD動画を見ると2分おきにバッファリングする。別の地域の中継回線に変えると正常。同じ時間帯にスマートフォンで同じ回線につないでも正常。」

良くない書き方：「すごく重いので早く直して。」

前者は回線と時間帯まで直接たどり着けますが、後者はサポートが最初から聞き直すことになり、往復に1日か2日かかります。

問い合わせる前にやる3つのこと

1つ目、クライアントと端末を再起動し、一時的な状態を除外します。2つ目、別の回線で再テストし、単一の回線か全体かを確認します。3つ目、アカウントの状態が正常で、通信量を使い切っておらず、プランが期限内であることを確認します。

この3つは合わせて5分もかかりませんが、かなりの数の問い合わせをふるい落とせます。

問い合わせる際にやってはいけない3つのこと

購読URLを問い合わせに貼らないでください。サポートが必要としているのは現象と確認結果であり、認証情報ではありません。1つの問い合わせに無関係な問題を3つ詰め込まないでください。分けて出したほうが早く処理されます。返信を待つ間に設定を何度も変えないでください。変えたあとでは現象が変わり、それまでに集めた情報が無駄になります。

問い合わせの送信後

問い合わせの入口はユーザーパネル内にあり、ログインすれば送信できます。送信後に同じ問題を重複して送らないでください。重複した問い合わせは処理順を乱します。

返金が必要な場合、本サービスは7日間の理由を問わない返金に対応しています。具体的な条件は利用規約のページをご確認ください。価格とプランの一覧はプランページに、回線の分布はノードページにあります。数字はここに書いたものと一致しています。