著者 Tailscaleが遅い原因は？直接接続と中継（DERP）の確認・改善方法
Tailscaleの通信が遅い原因の多くは、直接接続できずDERP（中継）を経由しているためです。tailscale statusコマンドで接続状態を確認し、UDPブロックやNAT設定を見直すことで、回線速度に近いパフォーマンスへ改善する方法を解説します。
Tailscale が低速になる理由：直接接続ではなく中継されているため
Tailscale は、接続が中継（リレー）されていると低速になり、直接接続であれば回線速度に近いパフォーマンスが出ます。直接接続では、暗号化された WireGuard パケットがマシン間で直接送受信されるため、両端のインターネット回線の性能を最大限に活かせます。一方、中継接続ではすべてのパケットが一度サードパーティのマシンを経由するため、そのマシンの遅延や帯域幅の制限を受けます。Tailscale のパフォーマンスに関する公式ページには、「直接接続は、ほぼ常に低遅延かつ高スループットを実現する」と明記されています。
アプリケーション側からは、この接続形態の違いを直接確認することはできません。ファイルコピーが遅い、SSH セッションの反応が鈍いといった現象として現れるだけです。そのため、まずは現在の接続形態を確認することが最初の作業となります。2 つのコマンドを実行すれば 1 分以内に判別でき、その後の対応は原因の解消に充てられます。作業を始める前に、コーディネーションサーバーと WireGuard データプレーンは別々のシステムであるという仕組みを理解しておくことが重要です。実際にデータが転送されるのはデータプレーンのみだからです。
直接通信か中継通信かを判別する2つのコマンド
測定を行う前に、ピアへトラフィックを送信してください。Tailscaleは要求に応じてパスを構築するため、今日通信していないピアはまだパスをネゴシエートしておらず、古い回答を読み取ってしまう可能性があります。ピアのtailnetアドレスに対して ping または curl を1回実行すれば十分です。
tailscale status回答は各ピアの行末に表示されます。
100.113.160.82 device-a tagged-devices linux active; offers exit node; direct 203.0.113.9:41641
100.104.93.78 device-b you@ android active; relay "tor"direct に続いてアドレスとポートが表示されている場合、パケットはそのアドレスへ直接送信されています。relay "tor" はDERPサーバー（designated encrypted relay for packets）を指しており、これはTailscaleの中継サーバーの一つです。この場合、そのピアへのすべてのパケットが中継サーバーを経由しています。3つ目の値である peer-relay については、次セクションで解説します。
tailscale ping device-b正常な接続は、まず中継経由で開始され、その後に直接通信へ切り替わります。最初のパケットは最寄りのDERPサーバーを経由して両マシン間のネゴシエーションが行われ、その後パスが切り替わります。
pong from device-b (100.113.160.82) via DERP(tor) in 51ms
pong from device-b (100.113.160.82) via DERP(tor) in 48ms
pong from device-b (100.113.160.82) via 203.0.113.9:41641 in 35ms--until-direct のデフォルト値が true であるため、実行はそこで停止します。直接通信が確立できない接続は以下のように表示され、pongの代わりに文章で終了します。
pong from device-b (100.104.93.78) via DERP(tor) in 53ms
pong from device-b (100.104.93.78) via DERP(tor) in 60ms
direct connection not established最後の行が判定結果です。これはTailscaleが予定していたすべてのプローブを送信しても、直接パスを確立できなかったことを意味します。最初の直接パスで停止させず、中継パスを監視し続けるには tailscale ping --until-direct=false -c 20 device-b を実行し、レイテンシのばらつきを確認してください。中継パスは、管理外のサーバーを介して2つのインターネットパスが結合されるため、通常は数値が高くなり、変動も大きくなります。
tailscale status における peer-relay とは何ですか？
peer-relay とは、直接接続が不可能な場合に、自身の tailnet 内の他のメンバーのためにトラフィックを中継するマシンのことです。これは指定した UDP ポートで待機し、tailscaled は DERP よりも優先的にこれを使用します。tailscale status はそのような接続をマークし、peer-relay、そして tailscale ping はリレーのエンドポイントを表示します。
pong from device-b (100.97.143.93) via peer-relay(203.0.113.42:40000:vni:1) in 4ms
direct connection not establishedこの点をよく理解してください。これは直接接続ではないため、通信経路は依然として direct connection not established で終了します。変更されたのは、誰が中継を行っているかという点です。パブリック IP アドレスを持ち、十分な帯域幅が確保された VPS は、共有の DERP ノードよりも自身のトラフィックを中継するのに適しています。これがサーバーをレンタルしているユーザーにとって重要である理由です。クリーンなパブリックエンドポイントを持つマシンで、以下のように有効化します。
sudo tailscale set --relay-server-port=400000 のポート指定はランダムな未使用ポートを選択し、空の文字列を指定するとリレーサーバーは無効になります。次に、tailnet ポリシーファイル内の tailscale.com/cap/relay 機能を使用して、クライアントデバイスにその使用権限を付与します。
{
"grants": [
{
"src": ["tag:us-east-vpc"],
"dst": ["tag:us-east-relays"],
"app": {
"tailscale.com/cap/relay": []
}
}
]
}リレーデバイスとクライアントデバイスの両方で Tailscale 1.86 以降が必要です。ポリシーファイルの編集に時間を費やす前に、各マシンで tailscale version を実行してバージョンを確認してください。daemon が試行する順序を覚えておくことは有益です。まず直接接続を試み、それが失敗した場合は使用許可のある peer-relay を探します。いずれも存在しない場合、DERP にフォールバックします。DERP が完全に排除されることはありません。なぜなら、DERP は 2 台のマシンが最初にネゴシエーションを行うためのチャネルでもあるからです。
原因 1: UDP をブロックする送信ファイアウォール
Tailscale では接続がリレー状態のままになる理由として 2 つを挙げており、その 1 つ目が UDP のブロックです。マシンに直接問い合わせます。
tailscale netcheckレポートはここで切り詰められますが、最上部のフィールドがすべてを決定します。
Report:
* UDP: true
* IPv4: yes, 203.0.113.9:41641
* IPv6: no
* MappingVariesByDestIP: false
* PortMapping:
* Nearest DERP: DallasUDP: false と表示されていれば、それが答えです。マシンが Tailscale のプローブサーバーへ UDP パケットを送信できないため、直接経路を確立できず、デーモンは TCP 443 番ポート経由の DERP にフォールバックします。このフォールバックがあるため、マシンは接続済みで到達可能であり、すべてのバイトがリレーされているという「正常」な状態に見えてしまいます。
2 つの送信ルールがドキュメント化されています。「内部デバイスから :41641 への *:* での UDP 送信を許可する」は WireGuard トラフィックそのものであり、「内部デバイスから *:3478 への UDP 送信を許可する」は、マシンが自身のパブリックアドレスとポートを学習するためのプロトコルである STUN (session traversal utilities for NAT) です。宛先にはワイルドカードを使用してください。Tailscale は随時リレーサーバーを追加するため、手動で作成したアドレスリストは 1 年以内に陳腐化します。
レンタルサーバーの場合、一般的な原因は厳格な送信ポリシーです。これは、ハードニング済みのイメージを継承しているか、プロバイダーが上位で適用しているかのいずれかです。まずデフォルトの送信ポリシーを確認してください。
sudo ufw status verbose
sudo nft list rulesetDefault: deny (incoming), allow (outgoing) であれば問題ありません。デフォルトの送信ポリシーが deny で、TCP 443 番ポートと DNS のみを許可する短いリストになっている場合、それがサーバーが常にリレー状態になる原因です。TCP 443 番ポート経由の DERP 経路はこの穴を通過できますが、直接経路は通過できないためです。これらのルールが実際にどこに存在するかは、サーバーが iptables と nftables のどちらで動作しているかに依存します。誤った方を編集しても何も変わりません。
インバウンド側も重要です。VPS はパブリック IP アドレスを持つため、ペアの「容易な側」になることができます。ファイアウォールが tailscaled がリッスンしているポートへのインバウンド UDP を許可していれば、複雑なルーター配下のピアも特別な工夫なしに接続できます。実際に使用されているポートを確認してください。
sudo ss -lunp | grep tailscaled
sudo ufw allow 41641/udp41641 はデフォルトの固定ポートです。randomizeClientPort 設定が有効な tailnet では、クライアントはランダムなポートを選択します。その場合は、このページの値ではなく ss の出力から実際の番号を取得してください。次に、プロバイダーのコントロールパネルを確認してください。多くのホストはサーバー内部とは別にネットワークファイアウォールを運用しており、ufw で追加したルールはそこには影響しません。
原因 2: 両端または片端のハード NAT
2 つ目に挙げられる原因はハード NAT です。NAT (ネットワークアドレス変換) とは、ルーターがプライベートアドレスをパブリックアドレスに書き換える処理を指します。一般的なルーターは、通信相手に関わらず、特定の内部ソケットに対して同一のパブリックポートを割り当てます。これはエンドポイント独立マッピングと呼ばれます。一方、ハード NAT は宛先ごとに異なるパブリックポートを割り当てるため、STUN サーバーから取得したアドレスをピアが利用できないという事態が発生します。Tailscale はこの状態を netcheck 内で MappingVariesByDestIP: true として報告します。
ハード NAT が片側だけであれば通信は可能です。相手側のパブリックエンドポイントが安定していれば、ハード NAT 内の端末から接続を開始して経路を確立できるためです。両端がハード NAT の場合は通信が失敗します。互いに相手のポートを予測できないためです。
パブリック IPv4 アドレスを持つ VPS の場合、この項目は false と表示されるはずです。アドレス変換が行われていないためです。もしレンタルサーバーで true と表示される場合、プロバイダーのネットワーク内のどこかでアドレス変換が行われています。この場合、サーバー内部のファイアウォール設定を変更しても解決しません。対策としては、クリーンなパブリックエンドポイントを持つマシンにピアリレーを設置するか、ワークロードを移行する必要があります。この状況では サブネットルーターからプライベート範囲をアドバタイズする 方法が有効です。ネットワーク内の全デバイスへの経路を確保するのではなく、ネットワークへの入り口を 1 つ確保すれば済むようになるためです。
なぜ出口ノードを使用すると Tailscale が実際より遅く見えるのか
出口ノードは2つ目のホップとなるため、ユーザーはトンネルの性能が低いと誤解しがちです。出口ノードを選択すると、リクエストはラップトップからトンネルを経由して VPS に到達し、そこからパブリックインターネットへ出ていきます。応答も同じ経路をたどります。VPS への接続がどれほど完璧であっても、合計の速度は VPS 自体のアップリンク速度を超えることはなく、追加された距離がページ読み込みのたびに遅延として現れます。
2つの区間を個別に測定してください。出口ノードをオフにし、VPS の tailnet アドレスに対してトンネル単体の性能をテストします。
sudo tailscale set --exit-node=
sudo apt install -y iperf3
iperf3 -sクライアントからその tailnet アドレスに対して iperf3 -c 100.113.160.82 を実行してください。その数値がトンネルの性能です。次に、sudo tailscale set --exit-node=100.113.160.82 で出口ノードを再度有効にし、パブリックインターネットに対して通常の速度テストを実行します。その数値がトンネルと VPS のアップリンクを合わせた性能です。最初の数値が良好で2番目の数値が悪い場合、問題は Tailscale ではなく、出口ノード自身のネットワークとサイジングに原因があります。どのノードを選択したか不明な場合は、tailscale exit-node list を実行すると現在利用可能なノードを確認できます。
CPU も出口ノードの性能上限を決定する要因です。Tailscale は、コア数が多いことよりも、クロック周波数が高い新しい世代の CPU を推奨しています。そのため、vCPU 数が多いプランが必ずしも高速になるとは限りません。混雑した共有ホストでは、割り当てられたはずの CPU リソースを完全には利用できず、隣接するノードによる CPU 奪い合いが発生すると、こちら側の設定を変更していないにもかかわらず、時間帯によってスループットが変動する現象が見られます。
唯一のチューニング項目: rx-udp-gro-forwarding
Tailscale は Linux の設定を 1 つだけ公開しています。これはトラフィックを転送するマシン、つまり出口ノードやサブネットルーターに適用されるものです。通常のクライアントには効果がありません。Tailscale 1.54 以降と Linux カーネル 6.2 以降が必要ですので、変更前に両方を確認してください。
tailscale version
uname -rこれらが準備できたら、インターネットに面したインターフェースで UDP GRO (generic receive offload) 転送を有効にします。
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off設定が反映されたか確認します。
ethtool -k $NETDEV | grep -E 'rx-udp-gro-forwarding|rx-gro-list'rx-udp-gro-forwarding: on と rx-gro-list: off が表示されるはずです。これが有効な理由は、Tailscale のトラフィックが UDP であるためです。カーネルが小さな UDP パケットを転送経路全体で結合したままにすることで、デーモンが処理するセグメントの数が減り、同じバイト数でも効率的に処理できるようになります。ethtool -K は再起動すると無効になるため、永続化が必要です。networkd-dispatcher を使用しているシステムでは以下のようにします。
printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscaleスクリプトを手動で一度実行し、終了ステータスが 0 であることを確認してください。また、転送ノードではそもそも IP 転送が有効である必要があります。これは別の設定項目であり、設定漏れによる障害の原因となります。
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conftailscale0 インターフェースはどの MTU を使用していますか？
推測するのではなく、マシンから直接読み取ってください。
ip link show tailscale0この出力に含まれる mtu の値が、実際のトンネルで使用されている値です。これはイーサネットインターフェースが報告する 1500 よりも小さい値ですが、バグではなく意図的なものです。トンネル内で送信されるすべてのパケットはカプセル化されます。IPv4 では 20 バイト、IPv6 では 40 バイトの外部 IP ヘッダー、8 バイトの UDP ヘッダー、そして 32 バイトの WireGuard フレームおよび認証タグが付与されます。これらすべてが、実際の通信経路で許容されるサイズに収まる必要があります。Tailscale は、PPPoE 接続や一部のモバイルネットワーク、IPv6 トンネルなど、1500 バイトのフルパケットを扱えないリンクでも通信できるよう、十分に低い値を自動的に選択します。
MTU 問題の症状は特有であるため、単なる低速化だけで判断しないでください。SSH は応答し、ping も動作する一方で、大容量の転送や大きな HTTPS ページが低速になるのではなく完全に停止する場合、それが MTU 問題の兆候です。このパターンは、パケットサイズが大きすぎてどこかで破棄されているものの、送信元に通知する ICMP メッセージが戻ってきていないことを意味します。tailscale0 の MTU を 1500 に近づけて引き上げると、収まらないパケットがさらに大きくなるため、状況は悪化します。根本的な解決策は、二分探索で適切なパス MTU を特定し、トラフィックを転送するルーター上で TCP MSS をクランプすることです。接続タイプによってこの事実は変わりません。リレー経路であっても直接経路であっても、同じインターフェース MTU が使用されます。
FAQ
Tailscale の接続が直接かリレー経由かを確認するには？
tailscale status を実行し、ピアの行の末尾を確認してください。direct 203.0.113.9:41641 は直接接続、relay "tor" はすべてのパケットがその DERP サーバーを経由していることを意味し、peer-relay はパケットが自身の tailnet 内の別のマシンを経由していることを示します。別の確認方法として tailscale ping <peer> を実行します。正常なパスであれば DERP で開始した後にプレーンなアドレスとポートを含む pong が表示されますが、リレー経由のパスでは終了まで DERP pong が表示され、最後に direct connection not established と出力されます。Tailscale は要求に応じてパスを構築するため、事前にピアへトラフィックを送信してください。
VPS で直接接続が確立されないのはなぜですか？
VPS 上で tailscale netcheck を実行してください。UDP: false と表示される場合、エグレスファイアウォールがアウトバウンドの UDP を遮断しており、デーモンが TCP 443 経由の DERP にフォールバックしています。これが、マシンが接続状態に見える理由です。ポート 41641 から任意の宛先へのアウトバウンド UDP、および任意の宛先のポート 3478 へのアウトバウンド UDP を許可してください。サーバー内部のファイアウォールだけでなく、プロバイダー側のネットワークファイアウォールも確認してください。これらは個別の制御であり、ufw ルールはプロバイダー側の設定には影響しません。
リレー経由の Tailscale 接続は直接接続より安全性が低いですか？
いいえ。DERP サーバーは復号できない WireGuard パケットを転送するだけです。暗号鍵は各デバイス上で生成され、外部へ送信されることはありません。リレーによる影響はレイテンシとスループットであり、機密性ではありません。コーディネーションサーバーが制御するのはデバイス同士の認識範囲であり、鍵素材と接続メタデータの分離については、どの程度を自己ホストするかを決定する前に理解しておく価値があります。
rx-udp-gro-forwarding 設定はすべてのマシンに有効ですか？
いいえ。これは他者のトラフィックを転送する Linux マシン（出口ノードやサブネットルーター）向けに文書化されています。自身のピアとのみ通信するラップトップやサーバーでは効果がありません。また、Tailscale 1.54 以降と Linux カーネル 6.2 以降が必要です。まず tailscale version と uname -r を確認してください。ethtool -K は再起動時にリセットされるため、永続化が必要である点に注意してください。
Tailscale は通常の WireGuard より低速ですか？
どちらも WireGuard を使用してトラフィックを暗号化します。Tailscale は、通常の WireGuard では手動で行う必要がある接続設定を自動化しており、その設定過程でリレーを経由することがあります。通常の WireGuard にはリレーが存在しないため、直接接続するか、接続に失敗するかのどちらかです。したがって、比較する際は条件を揃えてください。Tailscale のベンチマークは tailscale status が direct と表示されているときのみ行ってください。比較のために手動設定版が必要な場合は、自作の WireGuard サーバーには約 40 行の設定が必要であり、そのトレードオフについては 両アプローチの比較で解説しています。