VPNDT トラブル対応大全：症状から原因を切り分ける

問題が起きても、すぐにクライアントを入れ替えないでください。端末から国際回線の出口までの経路は、どこか一箇所でも問題が起きれば「開けない」という同じ症状になります。いきなり再インストールやリセット、ソフトの乗り換えを行うと、3 箇所を変えたのにどれが効いたのか分からない、という事態になりがちです。効率的なのは、まず経路を 4 つの層に分け、症状がどの層に当てはまるかを判断してから、該当する章に進む方法です。

4 層の使い方

診断は上から下へ進めます。L1 に問題がある場合——端末がローカルネットワークにすらつながらない場合——残り 3 層は見る必要がありません。クライアントがまったく接続できない場合は、L2 と L4 を重点的に確認します。特定のサイトやアプリだけが開けない場合は、L2 のルールか L4 の回線選びに原因がある可能性が高いです。層が判断できたら、本ページの該当する章がそのまま対処リストになります。

5 分でできる共通セルフチェック

• クライアントを終了し、端末自体がよく使うサイトに正常にアクセスできるか確認する。終了してもつながらない場合は、まずローカルネットワークを直す。
• クライアントの状態を確認する。「未接続」「接続中」「接続済み」のどれか。3 つの状態はそれぞれ別の章に対応する。
• サブスクリプションを最近更新したか確認する。長期間更新していないと、回線構成がすでに変更されている可能性がある。
• 最近ネットワークを変えていないか思い出す。自宅 Wi-Fi、社内ネットワーク、公共スポット、モバイルデータなど、ネットワークごとにポートとプロトコルの制限は異なる。
• システム時刻が自動同期になっているか確認する。時刻のずれが大きいと暗号化のハンドシェイクがそのまま失敗し、「どうしてもつながらない」という症状になる。
• 2 つ目のプロキシや高速化ソフトが同時に動いていないか確認する。2 つのソフトがシステムプロキシを奪い合うと、たいてい両方とも正常に動かなくなる。
• ユーザーパネルにログインし、プランが有効期間内で、通信量を使い切っていないか確認する。
• 問題が特定のサイト、特定のアプリ、特定の時間帯だけで起きるか記録する——この 3 つの情報が範囲を大きく絞り込む。

チケット送信前に用意する情報

問題が最終的にどの章に当てはまっても、まず次の項目を用意してください。利用しているプラットフォームとクライアント名、問題が始まった時刻と発生頻度、エラーメッセージの原文またはスクリーンショット、すでに試した手順と結果（どの回線に切り替えたか、どのネットワークに変えたか）、該当する回線の地域名、課金に関わる場合は注文番号。最終章では、これらの情報をそのまま使えるチェックリストにまとめています。

まず 3 種類の「つながらない」を区別する

1. 接続を押すと即座に失敗する、またはボタンが反応しない：クライアント層かローカルネットワーク層の可能性が高い。
2. 回り続けたまま最終的にタイムアウトする：回線に到達できないか、現在のネットワークが該当ポートを制限している可能性が高い。
3. 接続済みと表示されるのに、どのサイトも開けない：これは接続の問題ではないので、次の章「接続できるのにページが開かない」を参照する。

端末とローカルネットワーク層

まずクライアントを完全に終了し、端末自体がネットに接続できるか確認します。最も手っ取り早い切り分けはネットワークの切り替えです。Wi-Fi からモバイルテザリングへ、あるいはその逆へ切り替えてみてください。切り替えるだけで改善するなら、原因は元のネットワーク側の制限であり、アカウントや回線ではありません。社内ネットワーク、学内ネットワーク、一部の公共スポットは常用外のポートを制限しており、この種の制限はクライアント側では回避できません。ネットワークを変えるのが唯一の直接的な解決策です。

ルーターを長時間稼働させていると接続テーブルが枯渇し、「突然すべてつながらなくなった」という症状が出ます。ルーターを再起動すると、その一部は解決できます。あわせて、システム時刻が自動同期になっているか確認してください。時刻のずれが大きいと暗号化のハンドシェイクがそのまま失敗します。手動で時刻を変更した端末や、タイムゾーン設定が異常な端末では、この種の問題は珍しくありません。

クライアント層

まずクライアントを完全に終了してから起動し直します。ウィンドウを最小化するのではなく、プロセスを終了させてください。そのうえでクライアント内で回線を 1 本ずつ切り替えます。推奨する順序は、同じ地域の別回線 → 別の地域 → 回線タイプ（専用線、中継、直結）です。クライアントに転送プロトコルの選択肢がある場合は、2 本の回線の間でプロトコルを切り替えて再テストします。この手順で「現在のネットワークが特定の転送方式を苦手としている」ケースを除外できます。

次に、ファイアウォールやセキュリティソフトがクライアントのプロセスを遮断していないか確認します。Windows で最もよくあるのは、初回起動時のダイアログでうっかり「ブロック」を選んでしまい、その後クライアントが接続を確立できなくなるのに、何のメッセージも出ないというケースです。再インストールは最後の手段にしてください。再インストールの前に覚えておくこと：サブスクリプションはユーザーパネルにログインして取得し直すもので、ローカルのキャッシュに頼らないでください。再インストール後は改めてインポートすれば済みます。

アカウントとプラン層

ログイン状態が切れていることがあるので、一度ログアウトして再ログインします。ユーザーパネルでプランが有効期間内にあり、通信量を使い切っていないか確認してください。月額プランは ¥9.9/月で 60GB、¥18/月で 250GB、¥28/月で 500GB の 3 段階で、通信量は開通日を基準に毎月リセットされます。月間の通信量を前倒しで使い切った場合は、トラフィックパック（¥158/300GB、¥358/1000GB、¥658/3000GB、使い切るまで有効・期限なし）を選べます。

同時接続デバイス数は無制限なので、「デバイスが多すぎて強制切断された」という事態は本サービスでは起きません。逆に言えば、複数のデバイスが同じタイミングで一斉に失敗するなら、原因はアカウント、経路、またはローカルネットワークにあり、特定の 1 台ではありません。この判断だけで、端末ごとの切り分けにかかる手間を大幅に省けます。

サポートに問い合わせるべきタイミング

• 異なる地域の回線に 3 本以上切り替えても、まったく接続できない。
• ネットワークを変えても同様に失敗し、別のデバイスでも症状が完全に一致する。
• クライアントのログに明確なエラーコード、または再試行の繰り返しが記録されている。
• サブスクリプションをリセットしても接続できず、パネル上のプラン状態は正常である。

これらの結果を添えてチケットを送れば、「つながらない」とだけ伝えるよりはるかに速く進みます。サポートは、あなたが除外済みの方向を飛ばして調査を始められます。

まず 3 種類の症状を区別する

「開けない」は 1 種類の不具合ではありません。まずどれに当たるかを見極めてください。すべてのサイトが開けないのか、一部のサイトだけ開けないのか（国内サイトは正常）、それとも特定のブラウザだけ開けないのか。3 つの症状では対応する方向がまったく異なります。次の対照表をそのままたどってください。

全局とルールベース：1 回の再テストで方向を決める

クライアントは通常 2 つのモードを提供します。全局モードはすべての通信をトンネルに通し、ルールベースモードはルールに従ってトンネルを通すものと直結するものを振り分けます。診断ではまずモードを全局に切り替え、さきほど開けなかったサイトにアクセスします。開けるなら原因はルールにあり、第 7 章へ進んでください。それでも開けないなら、原因はプロキシの有効化、DNS、または回線にあるので、そのまま読み進めてください。この手順の価値は、1 回の操作で 1 つの方向を除外できる点にあります。

システムプロキシが有効になっているか

クライアントが「接続済み」と表示していても、システムプロキシが効いているとは限りません。Windows では「設定 → ネットワークとインターネット → プロキシ」で現在のプロキシのスイッチとアドレスを確認できます。macOS では「システム設定 → ネットワーク → 現在のネットワーク → 詳細 → プロキシ」で確認します。ブラウザの拡張機能、他の高速化ソフト、一部のダウンロードツールは、システムプロキシをこっそり書き換えて自分のポートに向けてしまうことがあります。プロキシアドレスがクライアントに表示されているものと違う場合は、それらのソフトを終了してから再テストしてください。

フラグメンテーションと MTU：つながるのに読み込めない

ハンドシェイクが成功し接続も正常なのに、ページがいつまでも読み込めない、または一部のサイトだけタイムアウトする場合は、パケットのフラグメンテーションが関係している可能性があります。トンネルのカプセル化はヘッダー長を増やすため、ネットワーク環境によってはパス MTU を超えた断片がそのまま破棄されます。クライアントは通常「自動」または手動の MTU オプションを提供しています。まずは自動のままにし、長期的に異常が続く場合にのみ妥当な範囲で微調整してください。しかも一度に変える値は 1 つだけ、変更したらすぐ再テストです。この段階で最も避けたいのは、複数のパラメータを一度に変えることです。

ブラウザ自体の DNS

現代のブラウザの多くは「安全な DNS」を内蔵しており、システム DNS を迂回してドメインを直接解決します。それが現在の回線に合わないアドレスを返すと、「クライアントは正常、他のアプリも正常、このブラウザだけ開けない」という症状になります。対処法は、ブラウザの安全な DNS を無効にするか「システムに従う」に設定し、ブラウザのキャッシュを一度消してから再テストします。

処理順序のまとめ

• 全局モードに切り替えて再テストし、ルールの問題か有効化の問題かを判断する。
• システムプロキシのスイッチを確認し、アドレスがクライアントと一致しているか確かめる。
• ブラウザの安全な DNS を無効にし、シークレットウィンドウで再テストする。
• 回線を 1 本変え、さらにネットワークも変えてみる。
• 別のデバイスで対照実験し、その端末固有の問題か確認する。

各ステップでは 1 つだけ実行し、終わったらすぐ再テストして結果を記録してください。この 5 ステップを終えても開けない場合は、第 8 章で DNS 解決の経路を扱います。

まず「遅い」を数値化する

遅いは主観的な感です。まず比較できる現象に変えてください。同じデバイス、同じサイト、同じ時間帯で、「クライアントを切って国内サイトにアクセス」と「クライアントを入れて目的のサイトにアクセス」をそれぞれ測定します。クライアントを切って国内サイトにアクセスしても遅いなら、原因はローカル帯域か Wi-Fi です。海外アクセスだけが遅い場合は、さらに読み進めてください。速度測定は 1 回のピーク値ではなく、複数回の中央値を見てください。単発の結果は瞬間的な変動に大きく左右され、回線品質を判断する材料としては不十分です。

回線タイプと適した用途

本サイトの回線は 3 つのタイプに分かれ、それぞれ適した用途が異なります。タイプ選びを間違えることが、「速度が遅い」の最もよくある原因の 1 つです。

夜間の混雑時間帯になぜ遅くなるのか

夜間の混雑時間帯のボトルネックは、通常はサーバー側ではなく海外接続の経路そのものにあります。この時間帯は国際回線全体が混雑し、家庭用ブロードバンドの上りも大量に使われます。使える手段は 3 つです。専用線の回線に切り替え、独立したチャネルで公共経路の待ち行列を避ける。近い地域（香港、日本、シンガポール）に切り替え、海外区間の長さを短くする。大容量タスク（OS 更新、クラウドストレージの同期、ゲームのアップデート）を混雑しない時間帯に移し、自分で帯域を埋め尽くさないようにする。

ローカル側の要因も見落とさない

• Wi-Fi の電波が弱い、または混雑した帯域で使っている。有線接続できるなら有線にするのが、最も手間のかからない一度きりの改善です。
• ルーターが古い、または長期間再起動していない。接続テーブルと転送性能の両方が低下します。
• バックグラウンドで OS 更新、クラウド同期、ネットストレージのダウンロードが動いており、上りを埋め尽くすとどの回線でも遅く感じます。
• ブラウザで大量のタブと拡張機能を開いており、ページ自体の読み込みも体感を悪化させます。
<>
• セキュリティソフトがフルスキャン中で、ディスクとネットワークが同時に占有されている。

どう測れば意味があるか

ツールを固定し、時間帯を固定し、複数回測ります。具体的な方法——どのツールを選ぶか、夜間の混雑時間帯と空いている時間帯にそれぞれ何回測るか、遅延とジッター、パケットロス、スループットがそれぞれ何を意味するか——は、ブログ 「VPN の速度測定はどうやる？自分で客観的に測る方法・ツール・時間帯」 に手順をまとめています。一度そのとおりにやってみれば、比較可能な記録が得られます。

よくある 2 つの誤判断

1 つ目は、ストリーミングの自動ビットレート低下を回線障害とみなすことです。プラットフォームはリアルタイムの帯域に応じて画質を自動調整するので、映像がぼやけるのはプラットフォームの仕様であり、回線の問題とは限りません。関連する仕組みは 「4K 視聴に向く VPN はどれか：画質が 480p に落ちる原因と見るべき回線指標」 を参照してください。2 つ目は、1 回のピーク値を結論にしてしまうことです。1 回測って速かった、遅かったという結果だけでは回線の長期的な性能を示せません。複数回の中央値を見るほうが信頼できます。

まず切断の規則性を記録する

切断の問題で最も困るのは「ずっと切れている気がする」という状態です。2 分かけて規則性を記録すれば、方向はすぐ明確になります。

• 一定時間ごとに切れる。たとえば 5 分や 30 分おき：キープアライブの仕組みかシステムポリシーが関係している可能性が高い。
• ランダムに切れる、規則性がない：ネットワークの揺らぎか、回線自体が調整中である可能性が高い。
• ネットワーク切り替え時だけ切れる。たとえば Wi-Fi とモバイルデータを相互に切り替えたとき：システムの再接続ポリシーの問題。
• 画面ロックやスリープの後だけ切れる：システムの省電力とバックグラウンド制限。
• 特定の時間帯だけ切れる：経路の混雑時間帯と関係している。

デスクトップ：スリープ、省電力、ネットワークアダプター

システムがスリープに入るとネットワーク接続が中断され、復帰後に一部のクライアントは自動で復旧せず、「わけもなく切れた」ように見えます。対処法は、クライアントで自動再接続を有効にする。システムの電源プランを「省電力」から「バランス」または「高パフォーマンス」に切り替えて再テストする。ネットワークアダプターのドライバー設定にある「電力節約のためにコンピューターでこのデバイスをオフにできるようにする」をオフにする、などです。また、クライアントが異常終了するとシステムプロキシのスイッチが元に戻らないことがあり、「切断後にもう二度とつながらない」という症状になります。システムプロキシの設定で手動でオフにしてから再接続すれば解決します。

モバイル：バックグラウンドポリシーが主因

iOS と Android はどちらも、画面ロック時や低電力時にバックグラウンドのネットワーク活動を制限します。iOS では低電力モードを有効にするとバックグラウンド更新とネットワーク活動が絞られ、画面ロック後に接続がシステムに停止されやすくなります。Android はメーカーごとにバッテリー最適化の方針の差が大きく、クライアントを「制限なし」のホワイトリストに追加し、バックグラウンド活動を許可する必要があります。さらに、OS のメジャーアップデート後に VPN 構成の権限を再確認する必要が生じることがあり、「OS を更新したらつながらなくなった」という症状になります。再許可すれば解決です。

ルーターと複数デバイスの環境

ルーター側で全局プロキシを構成している場合、ルーターのメモリと同時接続数の上限がボトルネックになります。同時に大容量ダウンロードを走らせると互いに帯域を奪い合い、「人数が増えると切れる」という症状になります。本サービスは同時接続デバイス数が無制限なので、複数デバイスそのものが互いを切断させることはありません。複数のデバイスが同じタイミングで一斉に切れる場合は、デバイス数ではなく出口の経路かローカルネットワークを先に疑ってください。

回線側の切断かローカル側の切断かを見分ける

• 同じアカウントの別デバイスも同時に切れるか？ 同時なら経路、1 台だけならその端末を指す。
• 回線を変えても切れるか？ 回線を変えて改善するなら、元の回線が現在の時間帯に不安定ということ。
• ネットワークを変えても切れるか？ ネットワークを変えて改善するなら、元のネットワーク側に問題がある。
• 切断時に国内サイトは正常か？ 国内もつながらないなら、海外接続の経路とは無関係。

4 つのうちどれか 1 つでも再現できれば、範囲は半分に絞られます。切断の時刻を記録し、ローカルネットワークの出来事（ルーターの再起動、OS 更新、回線事業者の揺らぎ）と照らし合わせると、原因が直接見つかることがよくあります。

サブスクリプションリンクの仕組み

サブスクリプションリンクはトークン付きのアドレスで、クライアントはこれを使ってサーバーから最新の回線リストを取得します。これは一種の資格情報と同じです。リンクを入手した人は回線をインポートできます。同じリンクを複数のデバイスにインポートでき、本サービスは同時接続デバイス数が無制限なので、デバイスごとに個別に申請する必要はありません。ここを理解しておけば、以降の「更新失敗」の対処はすべて筋道が通ります。リンク自体が失効しているか、クライアントがリクエストを送り出せていないかのどちらかです。

よくある失敗の症状と対処

プラットフォーム別のインポートと更新の手順

• Windows / macOS：クライアントを開く → サブスクリプション管理 → サブスクリプションを追加 → リンクを貼り付け → 更新。
• iOS / Android：クライアント内でサブスクリプションを追加した後、手動で一度下に引いて更新する。
• Linux：使用するクライアントの説明に従ってサブスクリプションをインポートする。コマンドラインクライアントでは設定ファイルのパスと権限に注意する。

すべてのプラットフォームのサブスクリプションはユーザーパネルから取得します。ログイン後にダウンロードとサブスクリプションのエリアでコピーしてください。本サイトは静的なサブスクリプションアドレスを一切提供していません。プラットフォーム別の手順は チュートリアルページ に、サブスクリプションリンクの概念、インポート、漏洩時の対処はブログ 「サブスクリプションリンクとは？初心者向け完全ガイド」 にまとめています。

リンクの漏洩とリセット

サブスクリプションリンクは資格情報と同じなので、公開グループやフォーラムに投稿したり、スクリーンショットに写り込ませたりしないでください。漏洩が疑われる場合は、ユーザーパネルでサブスクリプションリンクをリセットし、各デバイスで順に再インポートします。古いリンクはリセット後すぐに失効します。この手順は「リンクが速度制限を受けている、または異常に使われている」という問題の解決にも同時に役立ちます。

記事やチュートリアルに載っているサンプルリンクはすべてダミー値です。たとえば https://example.com/sub?token=YOUR_TOKEN のようなものです。本物のトークンに見えるアドレスは、公開の場に貼り付けないでください。

更新後に回線名が変わる場合

回線名とグループは運用に伴い調整され、名前の変更は利用に影響しません。特定の回線が消えた場合は、クライアントで同じ地域の別回線を選べば済みます。回線名が変わったからといってクライアントを何度も再インストールしないでください。再インストールでは回線の調整は解決せず、時間がかかるだけです。

ルールベース振り分けの基本ロジック

ルールベースモードでは、クライアントがドメイン、IP レンジ、またはプロセスごとに、通信をトンネルに通すか直結させるかを決めます。ルールがカバーしていない接続先は直結されるため、海外アクセスが必要な場面では「このアプリがプロキシを通らない」という症状になります。まずここを理解したうえで、どの種類のアプリかを確認してください。種類によって対処法は大きく異なります。

全局モードで素早く判断する

モードを全局に切り替えて再テストします。アプリが正常に戻れば原因はルールにあり、ルールを追加すれば済みます。それでも正常でない場合は、アプリの有効化の方式（そもそもシステムプロキシを読まないなど）か、そのアプリ自身が UDP や独自の DNS を使っている実装に原因があります。この手順を終えれば、以降の対処経路は 1 本だけになります。

よくあるいくつかのケース

• デスクトップソフトと同期ドライブ：一部はシステムプロキシを読まないため、クライアントの TUN / 仮想ネットワークアダプター方式で全通信を有効化する必要がある。
• Windows ストアアプリ：システムのネットワーク分離の影響を受けるため、クライアント側で対応する有効化オプションをオンにする必要がある。
• ブラウザ：拡張機能のプロキシがシステムプロキシを上書きするので、まず拡張機能を無効にして再テストし、その後で拡張機能内に設定するか判断する。
• コマンドラインツール：プロキシの環境変数を手動で設定する必要がある。下の例を参照。
• ゲーム：多くは UDP を使うため、UDP 転送に対応したモードが必要。またゲームは遅延に敏感なので、近い地域の回線を優先する。

コマンドラインのプロキシ設定例

export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
curl -I https://example.com

ポートはクライアントに実際に表示されている値を使ってください。上記はあくまで例です。Windows の PowerShell では $env:HTTPS_PROXY="http://127.0.0.1:7890" と書きます。設定後にコマンドラインは通るのにアプリは通らない場合、原因は回線やルールではなくアプリ自体にあります。

プラットフォーム別の有効化方式の対照表

処理順序

1. 全局モードで再テストし、ルールの問題か有効化の問題かを確認する。
2. 有効化方式を切り替える。システムプロキシでだめなら TUN / 仮想ネットワークアダプターモードに変える。
3. このアプリの接続先ドメインまたはプロセス用にカスタムルールを追加する。
4. それでも通らない場合は、単一プロセスのプロキシを試し、範囲を 1 つのプログラムに絞り込む。
5. ここまででだめなら、チケットにアプリ名と接続先サービスを添えて送ると、判断が進めやすい。

DNS 異常はどんな形で現れるか

• ページを開く前に数秒「解決中」の停止があり、その後に正常に読み込まれる。
• 同じサイトが一方のデバイスでは開け、もう一方では開けない。2 台は同じ回線を使っている。
• ドメインを入力しても開けないが、IP を直接指定すると開ける。
• ネットワークを変えると症状が消える。

これらの共通点は、「接続できるかどうか」ではなく「ドメインが何に解決されたか」に問題があることです。

診断コマンド

# Windows
nslookup example.com
ipconfig /flushdns

# macOS
dig example.com
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux
dig example.com
resolvectl flush-caches

「クライアントを起動した状態」と「終了した状態」で、同じドメインの解決結果をそれぞれ記録します。2 回の結果が同じなら、解決リクエストがトンネルを通っておらず、典型的な漏洩です。起動後に解決が遅くなる、または失敗する場合は、トンネル内の解決サービスが現在の回線から到達できないということなので、別の回線で再テストすれば済みます。

DNS 漏洩が意味するもの

DNS リクエストがトンネルを通らないと、ローカルネットワークや回線事業者の解決サービスに処理されます。影響は 2 層あります。1 つは、解決結果が近隣のアドレスになり、海外アクセスではかえって遠回りになること。「つながるが遅い」という症状になります。もう 1 つは、アクセスの意図がトンネルの外に露出することです。暗号化そのものには影響しませんが、ついでに直しておくべき問題です。

対処法

• クライアントの DNS オプションを「トンネル内の DNS を使う」または「システムに従う」に設定し、両方試して解決がより安定するほうを選ぶ。
• システム DNS を安定した公開の解決サービスに変更し、変更後にキャッシュを一度消す。
• ブラウザの安全な DNS を無効にし、システム設定に従わせる。
• ルーター側の DNS も一通り確認する。特にプロキシをルーターに載せている構成では重要。

本サイトの 「マイ IP」 ページでは、現在の出口 IP とその所在地を確認でき、通信が本当にトンネルを通っているかの確認に使えます。DNS の診断の前に出口を確認しておくと、見当違いの方向に時間を使わずに済みます。

「接続できるのに開けない」との関係

DNS 異常は第 3 章の「接続できるのにページが開かない」と同時に現れることがよくあります。推奨する判断順序は、まず第 3 章に沿ってプロキシの有効化とブラウザ設定を一通り確認し、そのうえで本章に戻って解決経路を扱うという流れです。両方の章を終えても異常が続く場合は、回線の変更や別デバイスでの対照実験を検討してください。

同時接続デバイス数は無制限

本サービスのプランは同時接続デバイス数を制限していません。複数デバイスの同時利用で制限がかかることはなく、「デバイス枠」を追加購入する必要もありません。むしろ注意すべきはアカウントの共有です。1 つのアカウントを複数人で共有すると、問題が起きたときにどのデバイス、どのネットワークの問題か判断しづらくなり、診断の手間が何倍にもなります。アカウントの共有はサブスクリプションリンクの拡散にもつながり、不要なリスクを招きます。複数のデバイスがすべて自分のものであれば、同時にログインして問題ありません。

アカウントとサブスクリプション関連の異常

• ログイン失敗：まずユーザー名とパスワードを確認する。忘れた場合はユーザーパネルの復旧手順へ。登録にメールアドレスは不要で、ユーザー名とパスワードだけで済むため、確認メールを待つ手順はありません。
• サブスクリプションが取得できない：サブスクリプションはユーザーパネルにログインして取得します。未ログイン、またはログイン状態が切れていると取得できません。再ログイン後にダウンロードとサブスクリプションのエリアでコピーしてください。
• プランの期限切れ、または通信量の使い切り：月額プランは ¥9.9/月で 60GB、¥18/月で 250GB、¥28/月で 500GB の 3 段階で、通信量は開通日を基準に毎月リセットされます。月間の通信量を前倒しで使い切った場合は、トラフィックパック（¥158/300GB、¥358/1000GB、¥658/3000GB、使い切るまで有効・期限なし）を選べます。途中でプランをアップグレードする場合、差額は残り日数に換算されます。
• 課金の疑問：注文に関わる疑問は、チケットに注文番号を添えると対応がずっと速くなります。

プランとトラフィックパックの詳細は プランページ に、回線の地域とタイプの一覧は サーバーページ にあります。回線を選ぶ前に照らし合わせてみてください。

サポートに連絡すべき 6 つのケース

1. 該当する章に沿って診断しても再現し、自分では判断を進められない。
2. ネットワークの変更、回線の変更、デバイスの変更の 3 つすべてで失敗する。
3. 複数のデバイスが同じタイミングで一斉に失敗する。
4. クライアントのログに明確なエラーコード、または再試行の繰り返しが記録されている。
5. サブスクリプションリンクをリセットしても更新できない。
6. 注文、返金、課金に関わる。返金の約束は 60 日間理由不問の返金です。条件に当てはまる場合は、チケットに注文情報を記載してください。

チケットに添える情報

• アカウントのユーザー名（パスワードは添えないでください）。
• プラットフォームとクライアント名。
• 問題が始まった時刻と発生頻度。
• 具体的な症状とエラーメッセージの原文。スクリーンショットがあるとなお良い。
• すでに行った手順と結果。たとえばどの回線に切り替えたか、どのネットワークに変えたか。
• 該当する回線の地域名。
• 課金に関わる場合は注文番号。

チケットの入口と対応の進み方

チケットの入口はユーザーパネルのチケットエリアにあり、ログインすれば送信できます。同じ問題で複数のチケットを重複して送らないでください。重複送信は対応順を乱し、かえって遅くなります。情報を追加したい場合は、元のチケットに追記すれば済みます。最もよくあるやり取りは「症状の説明が足りない」ことです。上のチェックリストをそのまま埋めれば、ほぼ一度で正確に伝わります。