WireGuardが遅いときの切り分け手順を実測で作った——DNS4秒はWindowsのkill-switch、MTUは外れ、トンネル内だけ1/10（WebARENA Indigo）
窓口（MCP サーバー）はつながりました。ところが本格的に使おうとして、パソコンの通信を固定の IP から出す役目が、窓口では果たせないと分かりました。それには VPN が要ります。
置き場所は、窓口と同じ WebARENA Indigo の VPS にしました。サーバー1台の料金で、転送量で請求が増えない。第2話で気にしていた通信料の心配がありません。そこに WireGuard を建て、パソコンの通信をまるごと通すようにしました。
建てたら、遅すぎて使い物になりませんでした。この回は、どこが遅いのかを区間に分けて測っていった記録です。先に書いておくと、最後まで速くはならず、原因も確定していません。
1. 同じ VPS に WireGuard を建てる
VPS は 2vCPU・メモリ2GB・回線100Mbps のプランです。第2話のとおり、自分の分は WireGuard を自分で建てることにしていました。窓口の隣で動かします。
受け付けの口は、UDP の口を1つ開けます。サーバーの中のファイアウォールと、Indigo の管理側のファイアウォールの2か所です。片方だけ開けて「つながらない」は、一度やりました。
端末を足すときは、ユーザーのパソコンで鍵を作り、こちらには公開鍵だけを送ってもらいます。秘密鍵はユーザーのパソコンから出ません。
パソコン側は、IPv4 の全通信をトンネルに通す設定にしました。
2. 遅いのは VPN だった
その日の夕方、ネットワークが重く感じました。パソコンには、この2日で Wi-Fi が20回切れた記録があり、私はパソコン側を疑っていました。
測ってみると、こうでした。
ページを開くたびに、最初の名前解決（ドメイン名から相手を探す処理）で約4秒待たされる
ダウンロードは 5〜10Mbps。トンネル無しなら 210〜240Mbps 出る回線です
家のルーターに ping を打つと、1つも届かない
トンネルを外すと、全部の数字が戻りました。Wi-Fi でもパソコンでもなく、VPN の経路が原因です。
4秒の待ちのほうは、先に説明がつきました。Windows 版の WireGuard は、相手のサーバーが1つで、全通信をトンネルに通す書き方（0.0.0.0/0）をすると、トンネルの外への通信を止める安全装置を自動で入れます。VPN が切れたときに、素の回線へ通信が漏れないためのもので、公式のドキュメントにも書かれています。家のルーターは、この「外」に入ります。ping が届かなかったのはこれで、Windows が家のルーターにも名前を問い合わせに行き、応答の無いまま時間切れ（約7秒）を待っていました。
公式の回避策は、全体を半分ずつ2本に分けて書くことです（0.0.0.0/1 と 128.0.0.0/1）。範囲は同じで全通信はトンネルに向きますが、「全体」とは書いていないので安全装置は入りません。ユーザーのパソコンの設定はいじらず、WireGuard の設定だけで直せます。この形にしてからは、ルーターにも届き、名前解決の待ちも無くなりました。
ただ、遅さのほうは、これとは別の話でした。
3. 区間に分けて測る
知りたいのは、VPS の力不足なのか、つなぎ方の問題なのかです。区間を3つに分けて、同じ量を流しました。
VPS 単体: 約95Mbps。プランの100Mbps どおりで、CPU もほとんど空いています。スペックは主因ではありません
パソコンと VPS の間を、トンネル無しで: 下り約90〜100Mbps、上り約80Mbps。自宅から VPS までの経路も十分に出ます
同じ区間を、トンネルの中で: 下りも上りも約9Mbps
VPS も経路も約90Mbps 出せるのに、トンネルを挟んだときだけ10分の1になる。トンネル無しの計測は TCP で、WireGuard は通信を UDP で運びます。疑う先は、トンネルそのものか、UDP の扱いか、の2つに絞られました。
4. MTU は外れ、サーバーの中でも落ちていない
最初に疑ったのは MTU、一度に送れるパケットの大きさでした。
WireGuard は、パソコンが送るパケットを暗号化して、UDP で包みます。包んだぶん大きくなるので、経路が通せる大きさを超えると、途中で分割されたり捨てられたりします。
経路が通せる大きさを測ると、約1460バイトでした。私の回線は、IPv4 を IPv6 の中に通して運ぶ方式の光回線で、その包みのぶん小さいのだと見ています。WireGuard の既定のままだと、包んだあとのパケットは1480バイトになり、これを超えます。計算は合っていました。
主因は MTU だと見立てて、サーバーとパソコンの両方の MTU を下げました。片方だけでは、片方向しか直りません。サーバー側で分割されたパケットを数えると、ほぼ0件。分割は無くなりました。
速度は、まったく変わりませんでした。約9Mbps のままです。見立ては外れました。ただ、外れたことで「パケットの大きさの問題ではない」と1つ消せました。
サーバーの中で UDP を取りこぼしていないかも見ました。受信のエラーも、送信の待ち行列からの破棄も、すべて0です。落ちているとすれば、サーバーの外です。
残った候補は3つでした。自宅の回線の IPv4 の経路。Indigo の網の側の、UDP の扱い。パソコンの USB の有線アダプタ。自宅の経路を避けて IPv6 でつなぐ手も考えましたが、この VPS には外から使える IPv6 が付いていませんでした。
5. WireGuard を通さずに、UDP だけを流す
最後に、WireGuard を通さない素の UDP を流して、どこで止まるかを確かめることにしました。
トンネルを止め、自宅の回線からだけ受け付ける UDP の口を一時的に開けて、サーバーから決めた速さで UDP をパソコンへ送らせました。速さは 20Mbps から 90Mbps まで、それぞれ数秒ずつです。
サーバーからパソコンへの UDP は、数千パケット届いたところで止まりました。速さを上げると、1つも届かなくなりました。
そして試験の直後から、サーバーそのものに外から届かなくなりました。SSH も、HTTPS も。同じサーバーの上の MCP の窓口も止まりました。自宅からは応答が無く、別の場所から試すと接続を断られる。網の側で止まっているのか、サーバーの中の何かなのかは、外からは区別できません。Indigo の管理画面では、サーバーは動いている表示のままで、遮断の通知もありませんでした。
再起動して数分後に、ようやく戻りました。届かなかったのは約15分です。効いたのが再起動なのか、時間がたって解けたのかは分かりません。戻ったあとのサーバーの記録にも、異常は残っていませんでした。
並行して、同じ症状の事例を調べる作業は AI に振っていました。上がってきたのは、利用者の報告として「UDP だけ異常に遅い」「VPN で少し流しただけで攻撃と判定された」というものが複数。回線の事業者が UDP を絞っている、という根拠は見つかりませんでした。
6. 分かったことと、分からないこと
疑ったものを並べると、こうなります。
観測した事実は3つです。TCP なら約90Mbps 出る同じ区間で、UDP のトンネルだけ約9Mbps。MTU を直しても変わらない。素の UDP を流した直後に、サーバーごと外から届かなくなった。
ここから、Indigo の網の側で UDP が絞られているのだと思っています。手元の観測とも、集めた利用者の報告とも、同じ方向を向いているからです。ただ、事業者が公表している仕様ではないので、どこで・何が・どういう条件で止めているのかは分かりません。問い合わせの文面は用意しましたが、送っていません。確定はしていません。
はっきりしているのは、私の使い方では WireGuard の UDP がまともに通らなかった、ということです。「転送量で請求が増えない」は、「UDP を自由に流せる」という意味ではありませんでした。少なくとも私にとって、ここは VPN の置き場所になりませんでした。
料金・仕様は2026年10月時点のものです。
次回：置き場所だけを変える
同じ WireGuard、同じ設定、同じパソコンのまま、サーバーだけを AWS Lightsail に移します。トンネルの中は、9Mbps から 120Mbps になりました。
