トラブル解決ガイド:症状別に原因特定

切り分けの枠組み:まず障害の層を特定する

トラブル対応でいちばん時間を食うのは、復旧そのものではなく、見当違いの方向に進んでしまうことです。同じ「つながらない」でも、原因はアカウントの状態、ローカルネットワーク、クライアント設定、対象サービス側のどこにでもあり、場所が違えば対処法もまったく変わります。いきなり回線を何度も切り替えると、同じ失敗を繰り返すだけで、本当の手がかりを覆い隠してしまいます。

本章ではまず、層ごとの切り分けフレームと、情報を集める際のチェックリストを示します。続く八つの章は症状別に展開し、どの章から読んでも構いません。ただし、まず 3 分ほど本章のトリアージ手順をたどり、問題がどの層にあるかを確認してから該当章へ進むことをおすすめします。はじめて本サービスを使う方は、使い方ガイド で登録、プラン選択、購読のインポートという流れをひととおり済ませてから、ここに戻ってきてください。

4 つの層がそれぞれ担うもの

アカウント層。アカウント層が扱うのは「接続する資格があるかどうか」です。購読が有効期間内か、当月の通信量を使い切っていないか、プランが期限切れになっていないか。この 3 点が、クライアントがサーバーから有効な回線設定を取得できるかどうかを決めます。VPNWing の月額プランは 3 段階で、¥9.9/月は 60GB、¥18/月は 250GB、¥28/月は 500GB。通信量は契約日を基準に毎月リセットされます。別途、トラフィックパック ¥158/300GB、¥358/1000GB、¥658/3000GB もあり、使い切るまで有効で期限はありません。当月の枠を使い切っている場合、クライアントは接続できてもすぐ切れる、あるいは購読が無効だと表示する挙動を示すことが多いです。途中でプランをアップグレードした場合、差額は残り日数に換算されるので、期間を計算し直す必要はありません。

ネットワーク層。ネットワーク層が扱うのは「ローカル側から外に出られるかどうか」です。ここには Wi-Fi の電波状況、ルーターの状態、利用中のネットワークが特定のポートを制限していないか、DNS が正常に解決できるかが含まれます。確認方法は単純で、クライアントを完全に終了し、端末のネットワークだけでよく使う国内のサイトをいくつか開いてみてください。この時点で開けないなら、問題は VPNWing とは関係ありません。

クライアント層。クライアント層が扱うのは「設定が正しいかどうか」です。クライアントのバージョン、購読が正しくインポートされているか、分割ルールが対象ドメインを直結に振り分けていないか、システムプロキシや仮想ネットワークアダプターが他のソフトに占有されていないか。この層の問題は回線の障害と誤解されやすく、症状も同じ「つながったのに開けない」になります。

対象サービス層。対象サービス層が扱うのは「相手側が正常かどうか」です。データセンターの IP 帯を制限するサイトもあれば、特定の時間帯にメンテナンスを行うサービスもあります。地域制限が回線と無関係で、出口の所在地だけに依存する場合もあります。確認方法は、別の地域の回線に切り替えて同じサイトを試すことです。すべての回線で失敗するなら、相手側の問題である可能性が高いです。

3 分トリアージ:順番にたどる

1. ユーザーパネルを開き、購読の状態、残り通信量、有効期限を確認します。これでアカウント層を除外します。
2. クライアントを完全に終了し、端末のネットワークだけでよく使うサイトを 2 つ開き、ローカルネットワーク自体が使えることを確認します。これでネットワーク層の基本的な疎通を除外します。
3. クライアントを開き直し、現在とは別の回線に切り替えます。地域も回線タイプも違うものを優先し、たとえば直結から IEPL 専用線に変えてみます。これで 1 本の回線の問題か、全体の問題かを切り分けます。
4. ブラウザで、まず先ほど動作を確認できたサイトを開き、そのあとで失敗していた対象サイトを開きます。2 つの結果を比べれば、「全体が不通」なのか「特定のサイトだけ不通」なのかを区別できます。
5. ここまで問題なく、それでも対象サイトだけ失敗する場合は、失敗時の具体的なメッセージを記録して、該当する章で詳しく調べます。

この 5 ステップを終えれば、ほとんどの問題は該当する章にたどり着けます。残りの時間は、試行錯誤の繰り返しではなく、細部の確認に使ってください。

同時接続台数についてよくある誤解

VPNWing は同時接続台数に制限がなく、1 つのアカウントで Windows、macOS、iOS、Android、Linux を同時に利用できます。端末ごとに個別の契約は必要ありません。そのため「接続数」「端末数」に関するメッセージが出た場合、多くはアカウントの上限ではなく、ローカル環境のコネクションテーブルが埋まっていることが原因です。

よくある原因は 2 つあります。1 つは家庭用ルーターの NAT セッションテーブルの容量で、同じネットワーク内で大量のダウンロード、動画、ゲームの接続が同時に発生すると新規接続が失敗し、「端末数の上限超過」とよく似た挙動になります。もう 1 つは OS 側のファイルディスクリプターやポートの枯渇です。どちらも共通する特徴は、一部の端末を切断したり大容量のタスクを止めたりすると、すぐに接続が戻ることです。この特徴に当てはまる場合の対処は、プランを変更することではなく、ルーターを再起動し、同時接続数を減らすことです。

サポートに連絡する前に用意する情報

情報がそろっているほど、原因の特定は早くなります。以下は一度に添えておきたい項目です。

• 登録時に使用したユーザー名。パスワードは不要です。
• 問題が起きているプラットフォームと OS のバージョン。例:Windows クライアント、macOS クライアント、iOS クライアント、Android クライアント、Linux クライアント。
• クライアントに表示されている回線名と回線タイプ。例:東京 · IEPL 専用線、香港 · 中継。
• 障害が始まった時刻、および継続的か断続的か。
• 再現手順:クライアントを開いてから問題が発生するまでの操作の順序。
• エラーメッセージの原文またはスクリーンショット。「つながらない」だけでは伝わりません。
• すでに試した確認項目。例:どの回線に切り替えたか、どのネットワーク環境で試したか、クライアントを再インストールしたか。

すぐにサポートへ連絡すべきケース

次の 3 つに当てはまる場合は、自己解決の確認を続けず、サポートへ連絡したほうが早いです。1 つは、同じアカウントのすべての端末・すべての回線が同じ時間帯に一斉に失敗する場合。2 つは、クライアントの起動時や購読のインポート時にエラーで終了し、メイン画面に進めない場合。3 つは、該当する章の手順をひととおり実行しても、問題が安定して再現する場合です。

サポートの窓口はユーザーパネル内にあり、送信後は同じ画面で返信を確認できます。請求や返金に関する問題であれば、VPNWing は 30 日間の無条件返金に対応しています。チケットに注文情報を記載すればよく、追加の書類は必要ありません。

まったくつながらない:3 つの段階を順に切り分ける

「まったくつながらない」とは、クライアントが接続を確立できない状態を指します。ボタンが回り続ける、進捗が途中の割合で止まる、あるいは「接続済み」になった直後に未接続へ戻る。この 3 つの原因は大きく異なるため、まずどれに当たるかを見分けるだけで、試行錯誤の大半を省けます。

3 種類の「つながらない」の違い

1 つ目はハンドシェイク前の失敗です。接続を押した直後にエラーになり、回っている時間もごく短いケースです。多くの場合、クライアントが回線の入口とセッションを張れていないことを意味し、原因はローカルネットワークか入口への到達性にあります。

2 つ目はハンドシェイク中の失敗です。数秒から数十秒回ったあとに失敗するケースです。ネットワーク経路自体は通じており、認証、設定の配信、暗号ネゴシエーションのどこかで止まっています。

3 つ目はハンドシェイク直後の切断です。一瞬「接続済み」と表示され、数秒で未接続に戻るケースです。設定の整合性、システムプロキシの競合、セキュリティソフトの遮断が関係していることが多いです。

ハンドシェイク前:まずローカル環境を確認

最初の一歩は常に素の接続での比較です。トレイへの最小化ではなくクライアントを完全に終了し、端末のネットワークだけでよく使うサイトを 2 つ開きます。ここで開けないなら、問題は VPNWing ではありません。まずローカルネットワークを対処してください。ルーターの再起動、Wi-Fi の帯域切り替え、あるいはモバイル回線に変えて比較する、などです。

2 つ目はシステム時刻の確認です。暗号化ハンドシェイクは証明書の有効期限検証に依存するため、長時間のスリープから復帰した端末や、手動でタイムゾーンを変更した端末では時刻が大きくずれ、ハンドシェイクが最初の段階で失敗します。しかもエラーメッセージは曖昧なことがほとんどです。各 OS の自動時刻同期はシステム設定にあります。オンにしてからクライアントを再起動して試してください。

3 つ目はセキュリティソフトの確認です。一部のウイルス対策ソフトやファイアウォールは、クライアントが作成する仮想ネットワークアダプターを異常なネットワークインターフェースと判定して遮断します。症状は、クライアントは接続済みと表示するのに、システムに新しいネットワークインターフェースが現れないというものです。対処はクライアントを許可リストに追加するか、一時的に保護を無効にして比較テストを行います。テスト後は必ず元に戻してください。

4 つ目は、2 つ目のプロキシソフトが動いていないかの確認です。2 つのクライアントが同時にシステムプロキシを掌握したり、同時に仮想ネットワークアダプターを作成したりすると、設定を上書きし合い、どちらもつながらなくなります。同時に動かすのは 1 つだけにしてください。

ハンドシェイク中:認証と購読

ネットワーク経路に問題がないと確認できたら、次は購読です。ユーザーパネルで 3 点を確認します。購読が有効期間内か、当月の通信量が残っているか、プランが期限切れになっていないか。どれか 1 つでも満たしていないと、クライアントは認証の段階で拒否されます。

購読のインポート失敗も「つながらない」として現れます。確認方法は、クライアントで手動で購読更新を一度実行し、成功の表示が出るかを見ることです。更新に失敗する場合は、後述の購読更新の章へ進んでください。完全な切り分け手順があります。

もう 1 つ、クライアントのバージョンと購読フォーマットが一致していないケースもあります。購読の内容はクライアントの種類に応じて異なる形式で配信されます。設定を手動で貼り付けたことがある場合、形式のずれが解析失敗を招きます。対処は現在の設定を空にして、パネルから購読を取得し直すことです。古い設定に追記しないでください。

ハンドシェイク後:つながってすぐ切れる

接続直後に切れる場合、よくある原因は 3 つです。

1 つは分割ルールとローカルネットワークの衝突です。たとえば、クライアント自身の更新用ドメインをルールがプロキシ側に振り分け、そのドメインがプロキシ側から到達できない場合、クライアントは起動時の自己チェックで失敗します。対処は、クライアントの更新用ドメインを直結ルールに追加するか、一時的にグローバルモードに切り替えて比較します。

2 つは MTU の不一致です。カプセル化後のパケットが経路上の MTU を超え、しかも正しく分割されないと、大きなパケットが破棄されます。症状は、つながったのに数秒で切れるというものです。この問題は一部のモバイル回線やダイヤルアップ環境でより多く見られます。詳しい確認方法は後述の「接続できるのにページが開けない」の章にあります。

3 つは、アカウントが別の場所で重複ログインしているケースです。VPNWing は同時接続台数に制限がありませんが、同じアカウントが短時間に多数の端末から繰り返しログインすると、サーバー側が保護的なレート制限をかけることがあります。対処は、他の端末が再接続を繰り返していないか確認することです。

症状別の対応表

それでもつながらないとき

地域もタイプも異なる回線を少なくとも 2 本(直結と IEPL 専用線を各 1 本)、ネットワーク環境も少なくとも 1 つ変えても、問題が安定して再現する場合は、サポートへ連絡してください。クライアントに表示されたエラーメッセージの全文、障害の発生時刻、試した回線名を添えると、対応時間を大きく短縮できます。

特定の回線が特定の時間帯だけ使えないという場合は、他の回線に切り替えて使い続けながら、チケットに具体的な回線名と時間帯を記載してください。的を絞った調査が可能になります。

接続できるのにページが開けない:分割、DNS、MTU

クライアントは接続済みでランプも緑なのに、ブラウザが回り続ける、あるいは一部のサイトだけ開けない。切り分けの中でもっとも多く、もっとも誤解されやすい類型です。原因はほぼ「回線が壊れた」ことではなく、「通信が正しい経路を通っているか」にあります。

まず 2 つの範囲を区別する

1 つ目はすべて不通です。接続後にどのサイトも開けず、以前は正常に開けていたサイトも含まれるケースです。原因は多くの場合、システムプロキシの設定、仮想ネットワークアダプターが通信を正しく引き受けていない、あるいは DNS が完全に機能していないことです。

2 つ目は一部不通です。一部のサイトは正常で、別のサイトは開けない。あるいは同じサイトでもトップページは開けるのに、詳細ページで失敗するケースです。原因は多くの場合、分割ルール、DNS の解決結果、または MTU にあります。

確認方法は簡単です。接続後に 3 つのサイトを順に開きます。国内のサイト、よく使う海外のサイト、そして先ほど失敗した対象サイトです。3 つの結果の組み合わせで、ほぼ方向性が定まります。

方向 1:分割ルール

分割ルールは、どの通信をプロキシ経由にし、どれを直結にするかを決めます。ルールの誤りには 2 つの典型的な現れ方があります。

1 つ目はプロキシを通すべき通信が直結になっているケースです。対象ドメインがルールで直結と判定され、リクエストがローカルネットワークからそのまま出ていくため、当然開けません。ルールセットの更新が遅れているときや、対象サイトがドメインを変更したときに起こります。対処は、クライアントのルール一覧で対象ドメインを検索し、どのルールに該当しているかを確認することです。直結と判定されている場合は、プロキシのルールを手動で 1 つ追加するか、一時的にグローバルモードに切り替えて検証します。

2 つ目は直結にすべき通信がプロキシを通っているケースです。国内のサイトがプロキシ経由になり、かえって遅くなったり失敗したりします。疎通自体は損なわれませんが、通信量を無駄に消費し、回線が遅いという誤解にもつながります。

見分け方:グローバルモードに切り替えて、もう一度試します。グローバルモードで対象サイトが開けるなら、原因は分割ルールです。グローバルモードでも開けない場合は、DNS と MTU の確認に進んでください。

方向 2:DNS 解決

DNS 問題の典型的な症状は、アドレスには ping が通るのにドメインで開けないというものです。原因は、名前解決が誤った結果を返しているか、解決リクエストにまったく応答がないことです。

確認方法は、コマンドラインで同じドメインを 1 回解決し、返ってきたアドレスが妥当かを見ることです。結果が明らかにおかしい、あるいはタイムアウトする場合は、DNS の段階だとほぼ確定できます。

対処法は 3 つあり、影響の小ささの順に並べます。

1. クライアントの DNS モードを切り替えます。多くのクライアントは、システムに従う、内蔵 DNS を使う、上流 DNS を指定する、といった選択肢を用意しています。内蔵 DNS に切り替えると、ローカル事業者の解決に起因する問題を回避できることが多いです。
2. 利用可能な上流 DNS を手動で指定します。設定後はシステムの DNS キャッシュを一度消してください。古い解決結果が使われ続けます。
3. ごく一部のドメインだけ解決がおかしい場合は、クライアントでそのドメインだけ解決方法を指定するか、アドレスを直接使ってアクセスし比較します。この方法は検証用で、日常的にはドメインを使うことをおすすめします。

方向 3:MTU と分割

MTU の問題は症状に特徴があります。小さいページは開けるのに、大きいページは途中で止まる。画像が欠ける、動画が最初のフレームで止まる、ログインページは送信後に回り続ける。原因は、カプセル化後のパケットが経路の許容長を超え、経路上の機器が分割に必要な制御メッセージを正しく返さないため、大きなパケットが黙って破棄されることです。

確認方法は、分割を許可しないプローブパケットで試すことです。Windows では ping の -f と -l を組み合わせ、macOS と Linux では ping の -D と -s を組み合わせて、パケット長を徐々に大きくしていき、分割なしでも応答が返る最大値を探します。これにヘッダー長を足した値が使用可能な MTU です。

対処は、クライアントまたは OS のネットワーク設定で MTU を下げることです。よく使われる値は 1400 前後ですが、具体的な値は上記のプローブ結果から決めてください。他人の数字をそのまま使わないでください。変更後は一度切断して再接続し、設定を反映させます。

コマンドラインで範囲を絞る

以下のコマンドは疎通確認のみに使い、アカウント情報は一切含みません。

# ドメインの解決結果を確認
nslookup example.com

# 対象に到達できるか確認(疎通確認のみ)
ping -c 4 example.com

# HTTP レスポンスヘッダーを確認し、ネットワークの問題かサイトの問題かを切り分ける
curl -I https://example.com

Windows では ping -c 4 を ping -n 4 に置き換えます。nslookup が異常なアドレスを返すなら DNS の問題、解決は正常なのに ping がすべてタイムアウトするなら経路か分割の問題、ping は通るのに curl -I がタイムアウトするなら MTU か対象サイト側の問題である可能性が高いです。

対処の順序

分割ルール、DNS、MTU の順に調べることをおすすめします。判断コストがこの順に上がるためです。分割ルールはグローバルモードへの切り替え 1 回で済み、DNS はコマンド 1 本、MTU は複数回のプローブが必要です。この順で進めれば、多くの問題は最初の 2 ステップで解決します。

3 ステップすべてに問題がないのに、対象サイトが開けない場合は、別の地域の回線に切り替えて試してください。切り替えで回復するなら、元の回線からそのサイトへの経路の問題です。記録してサポートへ連絡すれば十分です。切り替えても同じで、ローカルネットワークからそのサイトには正常にアクセスできるなら、対象側がその地域の出口を制限している可能性が高いです。

速度が遅い:帯域不足か経路の遠回りかを見分ける

「速度が遅い」はもっとも曖昧なフィードバックです。同じ「遅い」でも、ローカル帯域の不足、経路の遠回り、対象サイト側の速度制限、端末がバックグラウンドで別の処理を走らせているなど、原因はさまざまです。まずボトルネックを特定の区間に絞ってから、最適化の話をしましょう。

まずボトルネックがどの区間か確認する

アクセスの経路は 4 つの区間に分けられます。端末からルーター、ルーターからローカル事業者、ローカル事業者から回線の入口、回線の出口から対象サイト。どこか 1 区間でも混雑すれば、最終的な症状は「遅い」になりますが、対処法はまったく異なります。

基本的な判断原則があります。プロキシ経由の速度はローカル回線の帯域を超えません。ローカル回線の上りがもともと小さい場合、どの回線に変えても上り方向は速くなりません。同様に、家庭内の他の端末が OS アップデートやクラウド同期を行っていると、使える帯域が先に奪われます。

区間ごとに測る方法

1 つ目。クライアントを切断し、ローカルネットワークから国内のサイトまでの速度を 1 回測り、結果を記録します。これが基準値です。

2 つ目。クライアントを接続し、同じ地域のサイトまでの速度を 1 回測ります。この時点で明らかに低下するなら、問題は端末からルーターの区間にあります。Wi-Fi の電波強度、帯域(2.4GHz と 5GHz では実効スループットが大きく違います)、同一チャネルの干渉を確認してください。

3 つ目。クライアントを接続し、対象地域のサイトまでの速度を 1 回測ります。これが国際区間の品質を反映します。

3 つの結果を並べて見ます。1 つ目が遅ければローカルの問題。1 つ目が正常で 2 つ目が明らかに低下するならクライアントかルーターの問題。1 つ目と 2 つ目が正常で 3 つ目が遅いなら、そこで初めて国際回線の問題になります。

強調しておきたいのは、1 回の速度測定は変動が大きく、測定サーバーの負荷、時間帯、ブラウザのキャッシュに左右されることです。判断するときは 3 回以上続けて測り、単発のピーク値ではなく中央値を見てください。

回線選び:地理的な近さは最適な経路を意味しない

「近いほど速い」と考える人は多いですが、実際はそうとは限りません。国際回線の品質は、経路のホップ数、経由するバックボーン、専用チャネルを使っているかどうかで決まり、直線距離だけでは測れません。3 種類の回線の違いは次のように理解してください。

回線タイプの説明:IEPL 専用線は専用チャネル、中継はバックボーンノード経由、直結はローカルの出口です。地域とタイプの一覧は回線一覧ページで確認できます。

ある回線が日中は良好で夜になると明らかに遅くなる場合、共有回線がピーク時に混雑している可能性が高いです。IEPL 専用線に変えると改善することが多いです。どの時間帯でも遅い場合は、経路の遠回りの可能性が高く、タイプを変えるより地域を変えるほうが効果的です。回線選びの一般的な方法は地域・回線タイプ・用途から回線を選ぶの記事を参照してください。

クライアント設定の影響

見落とされやすい設定項目をいくつか挙げます。

• プロトコルと暗号スイート。暗号強度が高いほど計算コストも大きくなります。旧型のモバイル端末やエントリーモデルのルーターなど低消費電力の機器では、このコストがボトルネックになることがあります。端末の性能が限られている場合は、コストの低い組み合わせを選んでください。
• 多重化。有効にすると複数の接続が同じトンネルを共有し、ハンドシェイクの回数を減らせます。ただしパケットロス率の高い回線では詰まりを増幅させることがあります。オンとオフを切り替えて比較してみてください。
• 分割ルールの複雑さ。ルールの項目が極端に多いと、リクエストのたびにマッチングが走り、低性能な端末では体感できる遅延になります。ルールを絞るか、ドメインのサフィックス単位のマッチングに変えると緩和できます。
• バックグラウンドタスク。OS のアップデート、クラウド同期、写真のバックアップはバックグラウンドで帯域を使い、しかも夜間に自動で始まることが多いです。速度を調べる前に、これらのタスクの状態を確認してください。

プランの通信量が原因のこともある

速度低下と同時に接続が不安定になる場合は、まずユーザーパネルで当月の通信量を確認してください。VPNWing の月額プランは 3 段階で、¥9.9/月は 60GB、¥18/月は 250GB、¥28/月は 500GB。通信量は契約日を基準に毎月リセットされます。当月の枠が残り少なくなると、一部のクライアントは通知を表示します。

特定の月だけ使用量が多い場合は、トラフィックパックで補えます。¥158/300GB、¥358/1000GB、¥658/3000GB で、使い切るまで有効、期限はありません。トラフィックパックと月額プランの枠は別々に計算され、競合しません。長期的に現在のプランを超える使用量が続くなら、月額プランをアップグレードしたほうがお得です。差額は残り日数に換算されます。3 段階の詳細な比較はプランと料金ページで確認できます。

1 回の速度測定で結論を出さない

速度測定の結果は多くの要因に左右され、1 回の数字に参考価値はありません。ある回線が自分に合っているかを判断するには、自分のよく使う時間帯に、よく訪問するサイトで、数日間続けて観察するのが実用的です。多くの時間帯で安定しているなら、1 回の測定値が低かったという理由で乗り換える必要はありません。

上記の方法で区間ごとに測り、ボトルネックが国際回線にあると確認でき、しかも地域の異なる回線を少なくとも 2 本試しても改善しない場合は、3 回の測定時刻、回線名、結果をまとめてサポートへ送ってください。

夜間帯の混雑による重さ:混雑の原因と回線の切り替え

日中はまったく問題ないのに、19 時から 23 時ごろにかけて重くなる、動画が頻繁にバッファリングする、会議の音声が途切れる。これは多くの場合、機器の故障ではなく、国際回線の共有リソースがピーク時間帯に埋まっていることが原因です。

なぜ夜に集中するのか

国際アクセスの経路には共有区間があります。平日の夜は家庭のネットワーク利用がもっとも集中する時間帯で、動画、ゲーム、ダウンロード、ビデオ会議が一斉に流れ込み、国際出口の帯域が大量に消費されます。同時に、対象側のサーバーも自らのピーク時間帯にあり、応答速度が同じように低下します。

これは 2 つのことを意味します。1 つは、夜間の重さは往復の影響が重なった結果であることが多く、回線だけの問題ではないということ。もう 1 つは、同じタイプの回線に変えても改善は限定的である可能性が高いということです。新しい回線も同じ混雑区間を通るからです。

3 種類の回線のピーク時間帯における違い

回線タイプによって混雑への敏感さは異なります。

• IEPL 専用線は専用チャネルを通り、公衆インターネットの混雑区間を経由しないため、ピーク時間帯の影響がもっとも小さいです。代わりに単位コストが高く、安定性が重視される用途に向きます。
• 中継はバックボーンノード経由で転送し、前半は最適化された経路、後半は公衆回線を共有します。ピーク時間帯の挙動は専用線と直結の中間です。
• 直結はローカルの出口からそのまま外部に出るため、公衆回線に完全に依存し、ピーク時間帯の変動がもっとも大きくなります。

VPNWing は現在 120+ の国・地域と 160+ の回線を提供し、3 種類の回線タイプをカバーしています。日常のブラウジングなら直結で十分なことが多いです。夜間の混雑時間帯が主な利用時間なら、IEPL 専用線か中継を優先してください。回線の一覧とタイプの表記は回線一覧ページで確認できます。地域ごとにまとまっていて、各回線にタイプが明記されています。

まず家庭内の要因を除外する

問題を回線のせいにする前に、2 分ほどでローカルの要因を除外しましょう。

1. 家庭内の他の端末が大容量の通信をしていないか。OS のアップデート、クラウド同期、テレビボックスの動画キャッシュは帯域を使い、しかも夜間に自動で始まることが多いです。
2. Wi-Fi が近隣の同一チャネルの電波と干渉していないか。夜間は近隣の利用もピークで、2.4GHz 帯の干渉は明らかに強まります。5GHz 帯に切り替えるとすぐ改善することが多いです。
3. ルーターを長期間再起動していないか。家庭用ルーターのなかには、数週間連続で稼働するとセッションテーブルが断片化し、新規接続が遅くなるものがあります。一度再起動して比較してください。
4. 端末自体がクロックを落としていないか。ノート PC はバッテリー駆動時に性能が制限され、暗号化・復号のコストが相対的に増えます。

この 4 つを除外してから回線の問題と判断すれば、より正確になります。

できる 5 つのこと

1 つ目、用途別に回線を選ぶ。ビデオ会議や大容量ファイルの転送は IEPL 専用線を優先し、日常のブラウジングや短い動画は中継か直結で十分です。すべての場面で同じ回線を使う必要はありません。

2 つ目、大容量のタスクを時間帯からずらす。OS のアップデート、バックアップ、大容量ファイルのダウンロードは、日中や深夜に回してピーク時間帯を避けましょう。

3 つ目、同時接続を減らす。同じアカウントで同時接続台数に制限はありませんが、複数の高帯域タスクを同時に走らせると互いに帯域を奪い合います。夜間の混雑時間帯は不要なバックグラウンド同期を止めるとよいです。

4 つ目、不要な計算コストを減らす。性能が限られた端末では、コストの低い暗号の組み合わせを選ぶと処理能力に余裕が生まれます。

5 つ目、時間帯と回線を記録する。特定の回線が決まった時間帯に安定して遅くなるなら、記録しておきましょう。この記録は、回線の問題か全体の混雑かを判断するのに役立ち、サポートに連絡する際にもっとも有用な情報になります。

速度の保証について

補足しておくと、VPNWing は具体的な速度の数値を保証していません。国際回線の実効速度は、ローカル帯域、対象サイト、時間帯、経路など多くの要因に左右され、固定の速度保証は実態を反映できません。確認できるのは回線タイプとカバレッジです。120+ の国・地域、160+ の回線、3 種類の回線タイプから選択でき、同時接続台数は無制限です。

夜間の混雑による重さが通常の利用に支障をきたし、専用線タイプに変えても改善しない場合は、具体的な時間帯、回線名、利用シーンを添えてサポートへ連絡してください。この種の問題は回線ごとに個別に調べる必要があることが多く、情報が具体的なほど特定が早くなります。

切断が頻繁に起きるとき:再接続の戦略とネットワーク切り替え

切断は、つながらないことよりも苛立ちを招きます。進行中の作業を中断させるからです。切断の切り分けで重要なのは「再接続」ではなく、切断の規則性を見つけることです。間隔が一定か、特定の操作と同時に起きるか、特定のネットワークでだけ起きるか。規則性が確認できれば、原因はほぼ絞り込めます。

3 種類の切断パターン

1 つ目、間隔が一定。数分おき、あるいは数十分おきに、ほぼ同じ間隔で切れるケースです。キープアライブ機構、ハートビートのタイムアウト、サーバー側のセッション期限が関係していることが多いです。

2 つ目、ランダムに発生。決まった間隔がなく、何時間も切れないこともあれば、10 分で 3 回切れることもあるケースです。ネットワーク環境が関係していることが多く、Wi-Fi の電波変動、モバイル回線の基地局間の切り替え、上流回線の揺らぎなどが原因です。

3 つ目、アイドル後に切断。使用中は切れず、しばらく放置して戻ってくると切れているケースです。典型的な NAT セッションのタイムアウトで、故障ではなく想定内の挙動です。

確認方法は単純です。3 回以上の切断時刻を記録し、間隔が近いかを見ます。3 回あれば規則性は見えてきます。

規則的な切断:キープアライブとタイムアウト

間隔が一定なら、まずクライアントのキープアライブ設定を確認します。多くのクライアントはハートビート間隔やキープアライブのオン・オフを提供しており、有効にすると定期的に小さなパケットを送ってセッションを維持します。キープアライブが無効だと、経路上の中間機器が長時間データのないセッションを回収し、一定間隔で切れるという挙動になります。

2 つ目の確認点はサーバー側のセッション期限です。負荷分散のために、1 回の接続に時間上限を設けている回線もあります。その場合は、切れた直後にすぐ再接続でき、しかも同じ長さだけ安定して使えるという特徴が出ます。これに当てはまるなら故障ではなく、セッションの扱いが異なる回線に変えることを検討してください。

3 つ目の確認点はシステムのスリープです。ノート PC の蓋を閉じたり、モバイル端末をロックしたりすると OS がネットワーク活動を停止し、復帰時にはトンネルが失効しています。対処は、電源設定でスリープ中もネットワーク機器を維持するよう許可するか、復帰後に手動で再接続する習慣をつけることです。

ランダムな切断:ネットワーク切り替えと電波

ランダムな切断では、ネットワーク環境の確認が中心になります。

Wi-Fi の電波変動。ルーターから遠い、間に壁がある、周囲に同一チャネルの機器が多いといった条件でパケットロス率が上がります。ロスが一定の水準に達すると、クライアントはリンクが使えないと判断して再接続します。確認方法は、ルーターに近づいてもう一度比較することです。切断頻度が明らかに下がるなら、原因は電波です。

モバイル回線の切り替え。移動中は端末が基地局間を切り替え、そのたびにデータ接続が短時間中断します。クライアントが高速な再接続を行わない場合、切断として現れます。通勤経路では特に顕著で、ネットワークの特性によるものです。対処は、クライアントの自動再接続を有効にし、再試行間隔を短くすることです。

2 つの回線の併用。一部の端末は Wi-Fi とモバイル回線を同時に有効にし、OS が両者の間で賢く切り替えます。切り替わった瞬間にトンネルが失効します。デュアル回線の高速化が不要なら、どちらかをオフにすることをおすすめします。

上流回線の揺らぎ。同じネットワーク内の他の端末も同じ時間に通信断が起きているなら、原因はローカル事業者か上流にあり、VPNWing とは関係ありません。プロキシを通していない端末を同時に観察して判断してください。

アイドル後の切断:NAT セッションのタイムアウト

家庭用ルーターや事業者のゲートウェイは NAT セッションテーブルを保持しており、各エントリには生存時間があります。長時間データのない接続は回収され、回収されるとトンネルが切れます。これは NAT を使うすべてのネットワークで起こる現象で、VPNWing 固有の問題ではありません。

対処は 2 つあります。1 つはクライアントのキープアライブを有効にし、接続上に常に少量のデータを流すこと。もう 1 つはルーターの設定で NAT セッションのタイムアウトを延ばすことです。このオプションを提供するルーターもあり、「TCP タイムアウト」「セッション維持」といった名前になっていることがあります。

注意したいのは、キープアライブの間隔を短くしすぎないことです。短すぎるとクライアントが小さなパケットを送り続け、モバイル回線では消費電力が増えます。多くの場面では数十秒から数分の間隔で十分です。

システム側の干渉

見落とされやすい干渉源をいくつか挙げます。

• 省電力ポリシー。Windows の節電モード、macOS の低電力モード、Android と iOS のバッテリー最適化は、いずれもバックグラウンドでネットワーク活動を制限します。クライアントを許可リストに入れると回避できます。
• セキュリティソフトの通信制御。一部のセキュリティソフトはプログラムごとの通信を審査し、バックグラウンドで再接続要求を黙って遮断します。
• 仮想ネットワークアダプターの衝突。他の VPN や仮想マシンソフトをインストールした後、システムに複数の仮想ネットワークアダプターが残ることがあり、経路の優先順位が乱れて断続的な切断を招きます。使っていない仮想アダプターを整理すると改善することが多いです。
• システムプロキシの書き換え。一部のソフトは定期的にシステムプロキシ設定を書き換え、その瞬間に接続が切れます。そうしたソフトが動いていないか確認してください。

対処チェックリスト

1. 3 回以上の切断時刻を記録し、規則性があるか確認する。
2. クライアントのキープアライブを有効にし、改善するか観察する。
3. 別のネットワーク環境で比較する。たとえば Wi-Fi からモバイル回線に変える。
4. OS の電源・省電力設定を確認し、クライアントを許可リストに追加する。
5. 使っていない仮想ネットワークアダプターと余分なプロキシソフトを整理する。
6. 別の回線タイプの回線に切り替えて比較する。

チェックリストをひととおり実行しても切断が安定して続き、切断時刻と回線名を提供できるなら、サポートへ連絡してください。この種の問題はサーバー側のログと突き合わせて調べる必要があることが多く、時刻が正確なほど役立ちます。接続成功率や切断率を自分で測る方法は、安定性の自己測定方法の記事に再現可能な手順がまとまっています。

購読更新の失敗:アドレス・時刻・形式の 3 点を確認

購読はクライアントとアカウントをつなぐ設定経路です。クライアントは定期的に購読アドレスへリクエストを送り、回線一覧、分割ルール、接続パラメーターを取得します。購読更新の失敗は、クライアントが最新の設定を取得できないことを意味し、回線一覧が空になる、すべての回線がタイムアウト表示になる、設定が無効だと表示される、といった症状になります。

購読の仕組み

購読アドレスはトークン付きのリンクで、トークンはアカウントに紐づいています。クライアントがリクエストを送ると、サーバーはトークンからアカウントを識別し、対応する形式の設定内容を返します。この流れには 3 つの失敗ポイントがあります。リクエストを送り出せるか、サーバーがトークンを認識するか、返された内容をクライアントが解析できるか、です。

切り分けに置き換えると、アドレス、時刻、形式の 3 方向になります。

補足すると、購読アドレスはアカウントの資格情報です。ユーザーパネルでのみ取得し、公開の場に貼り付けたり、他人に送ったりしないでください。漏えいが疑われる場合は、パネルで再発行できます。

方向 1:アドレスそのもの

もっとも多い失敗原因はアドレスの欠損です。購読アドレスは長く、チャットやメール、メモからコピーすると途中で切れたり、改行や空白が自動で入ったりします。

3 点を確認します。アドレスが完全なプロトコルヘッダーで始まり、途中に空白や改行がないか。チャットソフトが自動認識して一部の文字をリンクや絵文字に変換していないか。末尾のパラメーター、とくにトークン部分が欠けていないか。

もう 1 つのよくある原因は、セキュリティソフトによるアドレスの書き換えです。一部のセキュリティソフトはすべての暗号化リクエストに対して中間者検査を行い、書き換えられたリクエストをサーバーがトークンとして認識できなくなります。確認方法は、クライアントで同じアドレスを 2 回リクエストしてみることです。2 回とも失敗し、ブラウザで他のサイトは正常に開けるなら、一時的にこの種の検査を無効にして比較してみてください。

方向 2:時刻と証明書

購読リクエストは暗号化接続を通り、証明書の検証はシステム時刻に依存します。システム時刻が大きくずれていると証明書が無効と判定され、リクエストはハンドシェイクの段階で失敗します。しかもクライアントの表示は通常「更新に失敗しました」だけで、具体的な理由は示されません。

確認方法:OS の時刻設定を開き、自動設定が有効になっていることと、タイムゾーンが正しいことを確認します。タイムゾーンをまたぐ移動、長時間のスリープ、手動での時刻変更は、ずれの原因になります。

時刻が正しいのに失敗する場合は、暗号化通信を傍受するソフトがインストールされていないか確認してください。そうしたソフトはシステムの証明書チェーンを置き換えるため、クライアントがサーバー証明書を検証できなくなります。

方向 3:形式の一致

購読の内容はクライアントの種類に応じて異なる形式で配信されます。クライアントの種類を誤って認識した場合や、一致しない形式を手動で選んだ場合、解析に失敗します。

確認方法:パネルで購読を取得し直し、クライアントの種類に合った形式を選びます。手作業で組み立てないでください。クライアントが複数の形式に対応している場合は、クライアントが自動認識した形式を優先してください。

形式の不一致のもう 1 つの現れ方は「更新は成功したのに回線一覧が空」です。リクエスト自体は成功していますが、返された内容が正しく解析されていない状態です。対処は現在の設定を空にしてから再インポートすることです。古い設定に追記しないでください。

コマンドラインでアドレスの到達性を確認する

以下の例ではプレースホルダーのアドレスを使い、方法の説明のみを目的としています。実際の購読アドレスに置き換えて公開の場に貼り付けないでください。

# 購読アドレスに到達できるか確認。レスポンスヘッダーのみ表示
curl -I "https://example.com/sub?token=YOUR_TOKEN"

# 返された内容の先頭数行を確認し、エラーページではなく設定であることを確かめる
curl -s "https://example.com/sub?token=YOUR_TOKEN" | head -n 5

1 つ目のコマンドが 4xx や 5xx を返す場合、サーバーがリクエストを拒否しています。トークンとアドレスの完全性を重点的に確認してください。200 が返るのに 2 つ目のコマンドの出力が設定テキストではなく Web ページなら、リクエストが中間機器に遮断またはリダイレクトされています。

再インポートの手順

1. ユーザーパネルで購読が有効な状態にあり、当月の通信量を使い切っていないことを確認します。
2. 購読アドレスをもう一度コピーします。コピー後はまずプレーンテキストエディターに貼り付け、余分な文字が入っていないか確認します。
3. クライアントで現在の設定を削除します。バックアップを先にエクスポートすることをおすすめします。上書きはしないでください。
4. 新しい設定を作成し、アドレスを貼り付けて、更新が完了するまで待ちます。
5. 回線一覧に内容があることを確認し、任意の回線を選んで接続テストを行います。
6. クライアントが対応していれば、自動更新を有効にし、妥当な間隔を設定します。

それでも失敗するとき

上記の 3 点に問題がないのに購読の更新が失敗する場合は、別のネットワーク環境で一度更新してみてください。公共ネットワークのなかには非標準のリクエストを遮断するものがあります。ネットワークを変えて成功するなら、元のネットワークに制限があるということです。

どのネットワーク環境でも失敗する場合は、サポートへ連絡する際に、更新失敗の具体的なメッセージ、使用中のクライアントのプラットフォーム、失敗が始まった時刻、複数のネットワーク環境で再現するかどうかを添えてください。購読アドレスの全体をチケットに貼らず、トークンの末尾数文字を伝えるだけにしてください。

特定のアプリだけプロキシを通らない:分割ルールと転送方式

ブラウザはすべて正常なのに、特定のアプリだけいつまでもつながらない。この種の問題は、これまでの章とは切り分けの考え方がまったく異なります。「ネットワークが不通」なのではなく、「そのアプリの通信が想定どおりトンネルに入っていない」のです。

なぜ特定のアプリだけうまくいかないのか

アプリによってネットワーク要求の扱い方は大きく異なります。システムプロキシに従うもの、独自にネットワークスタックを実装するもの、アドレスを直接使って名前解決を完全に飛ばすもの、UDP を優先するものもあります。分割ルールは通常ドメインかプロセスでマッチングするため、アプリの挙動がルールの範囲を超えると、通信が漏れ出します。

最初の一歩は、そのアプリの通信が実際にプロキシを通っているかを確認することです。方法は、クライアントを接続した状態で、クライアントの接続ログにそのアプリのリクエスト記録があるかを見ます。記録がなければ通信はトンネルに入っておらず、記録があるのに失敗しているならトンネルには入ったが相手側に拒否されています。

原因 1:システムプロキシを読まない

システムプロキシは一種の取り決めで、アプリは従うことも無視することもできます。一部のアプリは直接接続を張り、システムプロキシの設定を参照しません。そのため通信はトンネルを迂回してそのまま出ていきます。

対処は、クライアントを TUN モードに切り替えることです。仮想ネットワークアダプターモード、拡張モードと呼ぶクライアントもあります。TUN モードはネットワーク層で通信を引き受けるため、アプリがシステムプロキシに従うかどうかに依存せず、適用範囲が広くなります。

代わりに、TUN モードはより高いシステム権限を必要とし、一部の OS ではセキュリティソフトと衝突することがあります。切り替え後にシステムのネットワークがおかしくなったら、まずモードを戻してから調べてください。

原因 2:解決先アドレスのハードコード

アプリによっては解決サーバーのアドレスを内蔵していたり、サーバーのアドレスを直接埋め込んでいたりして、システムの名前解決を完全に飛ばします。この場合、分割ルールに対応するドメインを書いてもマッチしません。

確認方法:クライアントの接続ログで宛先アドレスを見ます。ログにドメインが表示されていればシステムの解決を通っており、アドレスが表示されていればアプリ自身が処理しています。

対処は 2 つあります。1 つは、そのアプリの宛先アドレス帯をプロキシルールに追加すること。もう 1 つは、クライアントをグローバルモードに切り替え、すべての通信をトンネルに入れることです。グローバルモードは一時的な利用にとどめてください。長期に有効にすると通信量を無駄に消費し、国内のサイトも遅くなります。

原因 3:UDP と QUIC

多くのプロキシプロトコルは TCP への対応は完全ですが、UDP への対応は実装によります。アプリが主に UDP を使う場合、たとえば音声通話、リアルタイム対戦ゲーム、一部のメッセンジャーなどで、クライアントが UDP 転送を有効にしていないと、それらの通信はそのまま失敗します。

関連するもう 1 つの問題が QUIC です。QUIC は UDP を基盤とし、多くのサイトが優先的な転送方式として採用しています。UDP が遮断され、クライアントがフォールバックを行わない場合、ページが回り続けるのに別のブラウザでは開ける、という症状になります。

対処:クライアントに UDP 転送のオプションがあれば有効にします。ブラウザだけに影響している場合は、ブラウザの設定で QUIC を無効にし、TCP へ強制的にフォールバックさせます。ゲームや音声通話のアプリでは、UDP 対応の良い回線を優先してください。

原因 4:証明書ピンニング

少数のアプリはサーバー証明書のフィンガープリントをコードに埋め込み、特定の証明書だけを信頼します。こうしたアプリは中間者による復号が行われると必ず失敗しますが、プロキシはまさにそれに近いことを行います。

症状は、アプリがネットワーク異常や安全でない接続と表示するのに、同じ端末のブラウザでは同じサービスに正常にアクセスできるというものです。この種の問題はクライアント側に解決策がないことが多く、そのアプリのドメインを直結ルールに追加してローカルネットワークから出るようにするしかありません。ローカルネットワーク自体からそのサービスにアクセスできない場合は、アプリ側の対応を待つほかありません。

アプリの種類別の対応表

切り分けの順序

1. そのアプリの通信がクライアントのログに現れるか確認します。記録がなければ「システムプロキシを読まない」の系統です。
2. 記録はあるのに失敗する場合は、ログの宛先がドメインかアドレスかを見ます。アドレスなら、ハードコードとルールの網羅性を確認します。
3. UDP が関係しているかを見ます。QUIC を無効にするか UDP 転送を有効にして比較します。
4. それでも失敗する場合は、証明書ピンニングを確認し、そのアプリのドメインを直結ルールに追加して比較します。

特定の回線がそのアプリに向かないと確認できた場合は、別の回線タイプで試してください。どの回線でも同じなら、アプリ名、プラットフォーム、クライアントログの宛先アドレスを記録し、サポートへ連絡する際に添えてください。リモートワークでの会議・コラボレーションツールの回線選びの違いは、リモートワークの回線選びの記事を参照してください。

モバイルの切断と DNS 解決の異常

モバイルの問題には 2 つの源があります。OS によるバックグラウンドアプリの制限と、ネットワーク切り替え後に解決結果が残ることです。この 2 つはデスクトップではほとんど起きませんが、モバイル端末ではかなりよく起こります。

モバイルでバックグラウンド切断が起きる理由

モバイル OS は省電力のため、バックグラウンドアプリに厳しい制限をかけます。クライアントがバックグラウンドに回されると、OS が一定時間後にネットワーク活動を凍結し、トンネルが失効することがあります。フォアグラウンドに戻るとクライアントは再接続が必要になり、その間数秒から数十秒の中断が生じます。

これは OS の設計によるもので、クライアントの故障ではありません。確認方法は簡単です。クライアントをフォアグラウンドに保ち、それでも切断されるかを見ます。フォアグラウンドでは安定し、バックグラウンドで切れるなら、OS のバックグラウンド制限です。

iOS と Android の違い

iOS はバックグラウンドのネットワーク制限がより厳格です。OS は VPN 系アプリに一定のバックグラウンド処理時間を与えますが、無期限に維持するわけではありません。長い時間使わないと接続が OS に回収されることがあります。iOS で設定できることは限られており、主にクライアントのバックグラウンド更新を許可する、低電力モードをオフにする、長時間接続を維持したいときはクライアントをフォアグラウンドに置く、といった対応になります。

Android は差がより大きく、メーカーごとに OS レベルで追加の省電力最適化が行われています。よくある設定項目は、バッテリー最適化の許可リスト、バックグラウンド動作の制限、自動起動の権限、バックグラウンドをロックするといったメーカー独自のスイッチです。特定のメーカーの端末でとくに切れやすい場合は、まずこれらを確認してください。

Linux デスクトップはモバイルではありませんが、同様の電源管理の問題があります。ノート PC の蓋を閉じてスリープさせた後、ネットワーク機器の再初期化が必要になり、トンネルが失効することがあります。

モバイルを安定してオンラインに保つ設定

プラットフォームごとに対処します。

1. OS の設定で該当のクライアントを見つけ、バッテリー最適化を「制限なし」にするか、許可リストに追加します。
2. バックグラウンドでの動作とバックグラウンドデータの使用を許可します。
3. OS のスマート省電力・スーパー省電力モードをオフにするか、これらのモードでクライアントを例外に追加します。
4. クライアントの設定で自動再接続を有効にし、再試行間隔を適度に短くします。
5. モバイル回線で使う必要がない場合は、Wi-Fi 接続時のみ接続を維持する設定にすると、切り替えによる再接続を減らせます。

これらの設定で切断頻度は下がりますが、完全にはなくなません。モバイル回線自体の切り替え、電波の届かない場所、OS によるリソース回収は短い中断を生みます。これはモバイル環境に固有の特性です。

DNS 異常の典型的な症状

解決の問題はモバイルでより多く見られます。端末が Wi-Fi とモバイル回線の間を頻繁に切り替え、そのたびに解決サーバーが変わる一方、システムのキャッシュには前回の解決結果が残っていることがあるためです。

典型的な症状は 3 つあります。アドレスには ping が通るのにドメインで開けない、解決の段階で失敗しているのに経路は通っている。一部のドメインが誤ったアドレスに解決され、開いても想定したページが表示されない。ネットワーク切り替え後しばらくすべてのドメインが開けず、数分で自然に回復する。これはキャッシュの期限切れによる自己修復です。

確認方法:OS 標準のネットワーク診断ツール、または解決結果を照会できるアプリを使って、同じドメインを 1 回解決し、結果が妥当かを見ます。PC で調べた結果と異なるなら、解決の段階だとほぼ確定できます。

プラットフォーム別の解決キャッシュの削除

キャッシュを削除すると、新しい解決結果がすぐに反映されます。

• Windows:コマンドプロンプトで ipconfig /flushdns を実行します。
• macOS:sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder を実行します。
• Linux:ディストリビューションによって異なります。systemd-resolved を使うシステムでは sudo resolvectl flush-caches を実行します。
• iOS と Android:OS に公開されたキャッシュ削除の入口はありません。もっとも直接的な方法は、機内モードを一度オン・オフするか、端末を再起動することです。

削除後は、クライアントの解決方法を内蔵の解決に設定し、ローカル事業者の解決結果の影響を受けないようにすることをおすすめします。現在の出口の所在地だけを確認したい場合は、サイト内のIP チェックページで照会できます。

判断の順序とまとめ

モバイルの問題は次の順序で調べることをおすすめします。

1. フォアグラウンドでの切断か、バックグラウンドでの切断かを確認します。バックグラウンドなら、OS の省電力設定の系統です。
2. モバイル回線でのみ起きるかを確認します。そうなら、ネットワーク切り替えと電波を確認します。
3. すべてのドメインが失敗するのか、一部のドメインだけかを確認します。すべてなら解決とトンネルの状態、一部なら分割ルールを確認します。
4. 解決キャッシュを削除し、クライアントの解決モードを切り替えて、もう一度試します。

順番に試しても頻繁に切断される場合は、サポートへ連絡する際に、端末の型番と OS のバージョン、クライアントのプラットフォーム、切断時のネットワーク種別、バックグラウンド時に起きるかどうかを添えてください。これらの情報は、OS の制限かクライアントの挙動かを判断する助けになります。

補足すると、VPNWing は同時接続台数に制限がなく、モバイル端末と PC で同じアカウントを同時に使えます。モバイル端末のために別途契約する必要はありません。モバイルでときどき切れるという理由だけで方法を変える前に、まず上記の手順で設定を調整してみてください。多くの場合は明確に改善します。