リモート拠点やモバイル回線からVPN経由でSSHしたとき、やけに応答が遅いと感じたことはないでしょうか。Tailscale（WireGuardベースのゼロコンフィグVPNサービス）を使っている開発者やSRE（システム信頼性エンジニア）に向けて、その遅延の正体と対処の選択肢を整理します。
実測値として、モバイル5G回線からホームラボへの接続で84.2msというリレー遅延が観測され、自前のリレーサーバーに切り替えることで14.1msまで短縮できたという計測結果があります。約83%の遅延削減です。この現象がなぜ起きるのか、そして自分の環境が該当するのかを順に見ていきます。
何が起きているのか：DERPリレー経由による遅延スパイク
TailscaleはWireGuard（軽量で高速な暗号化VPNプロトコル）を基盤にしていますが、WireGuard自体にはピア同士を自動的に発見する仕組みがありません。
そこでTailscaleは「コーディネーションサーバー」と呼ばれる制御プレーンを用意し、公開鍵交換やNAT越え（STUN/ICEによるホールパンチング）を仲介しています。通信経路自体はピア間で直接流れる設計です。
問題はNAT越えに失敗したときです。対称NAT（シンメトリックNAT）と呼ばれる厳格なファイアウォール環境や、携帯キャリアのCGNAT（複数ユーザーでIPアドレスを共有する仕組み）下では、直接のUDP通信が確立できません。
この場合Tailscaleは「DERP（Designated Encrypted Relay for Packets）」という中継サーバーにトラフィックを迂回させます。公式のDERPサーバーは地理的に離れていることがあり、70ms〜180ms程度の遅延が追加で発生するケースが報告されています。
なぜ起きるのか：コーディネーションサーバーの所在地問題
原因を分解すると3層に分かれます。1つ目は物理的な距離です。公式DERPサーバーの拠点が自分の利用地域から遠い場合、往復の通信時間（RTT）がそのまま遅延に乗ります。
2つ目は共有リレーであることです。不特定多数のユーザーが同じDERPサーバーを使うため、混雑時にスループットが低下します。計測例ではiperf3によるスループットが48.5Mbpsにとどまり、専用リレーに切り替えた場合の340.2Mbpsと比べて約6倍の差が出ています。
3つ目は無料プランの制約です。Tailscaleの個人向け無料枠には接続ノード数の上限があり、ホームラボでProxmox（仮想化基盤）やTrueNAS（NASソフトウェア）を含む複数ノードを管理していると、この上限に引っかかる可能性があります。
自分の環境が該当するか確認する方法
まず手元の接続が直接通信（P2P）なのか、DERPリレー経由なのかを確認します。Tailscaleのクライアントには状態確認コマンドが用意されています。
tailscale status出力の各ピアの行に表示される接続方式を確認してください。directと表示されていればP2P接続、relayと表示されていればDERP経由です。
さらに詳しい診断にはpingコマンドを使います。
tailscale ping <対象ノードのIP>このコマンドは経路がダイレクトかリレー経由かを明示し、実測レイテンシも表示します。リレー経由で100msを超える値が出ている場合は、本記事で扱う最適化の対象になります。
あわせて確認したいのが接続ノード数とプラン上限です。Tailscale管理コンソールの「Machines」ページで現在の接続台数を確認し、無料プランの上限に近づいていないかチェックしてください。CGNAT環境（携帯回線やキャリアの共有IP）からの接続が多い構成ほど、リレー依存度が高くなる傾向があります。
対策の選択肢と手順
対処法は大きく2つに分かれます。1つ目は、最も手軽な方法としてセルフホストのDERPサーバーを自前のVPS（仮想専用サーバー）に構築する方法です。
これはTailscale公式のアカウントを使い続けながら、リレーサーバーだけを自分の管理下に置くアプローチです。地理的に近いVPS（たとえば利用者の多い地域に近いHetzner CloudやConoHaなどのリージョン）を選ぶことで、リレー遅延を大幅に縮小できます。月額3〜4ドル程度の小型VPSでも、公式リレーより近い場所に置くだけで効果が出ます。
2つ目は、より踏み込んだ方法としてHeadscale（Tailscaleのコーディネーションサーバーをオープンソースで再実装したGo製ソフトウェア）への移行です。これはコーディネーションサーバー自体を自前のVPSに置き換える方法で、Tailscale社のクラウド基盤への依存そのものをなくします。
Headscaleを使う場合でも、クライアント側は公式のTailscaleアプリ（iOS、Android、macOS、Linux、Windows対応）をそのまま利用できます。切り替えが必要なのはサーバー側だけです。
Headscaleの導入を検討する場合、公式リポジトリ（juanfont/headscale）のドキュメントにあるDocker Compose構成を確認するところから始めるのが無難です。Ubuntu 24.04 LTSのようなクリーンな環境にDockerとDocker Composeをインストールし、設定ファイル（config.yaml）でサーバーのドメインとDERPマップを指定する流れになります。
接続ノード数の上限がない点、コントロールプレーンのRAM消費がSQLiteバックエンドで数十MB程度と軽量な点は、ホームラボや複数拠点の検証環境を運用する場合に判断材料になります。
tailscale statusとtailscale pingで先に切り分けることが、対策の方向性を誤らないための第一歩です。自前DERPとHeadscaleのどちらを選ぶかは、現状の依存度で判断できます。<table><tr><th>状況</th><th>推奨する対策</th></tr><tr><td>公式アカウントのまま遅延だけ改善したい</td><td>自前DERPサーバーを近いリージョンに追加</td></tr><tr><td>接続ノード数の上限に達している</td><td>Headscaleへの移行を検討</td></tr><tr><td>クラウド依存自体をなくしたい</td><td>Headscale + 自前DERPの組み合わせ</td></tr></table>
導入前に確認すること
まずtailscale statusとtailscale pingで、現在の接続がP2Pかリレー経由かを確認してください。
リレー経由で遅延が大きい場合は、利用地域に近いVPSでの自前DERP構築を試す価値があります。接続ノード数やプラン上限が問題になっている場合は、Headscaleの公式ドキュメントとDocker Compose構成を確認するところから始めてみてください。
どちらを選ぶにしても、WireGuardの暗号化通信自体はそのまま維持されます。変わるのは制御プレーンとリレー経路の置き場所だけです。