Anycast（同じIPアドレスを複数の拠点から広告する方式）のトラブルは、「どこか1か所で起きているのに、見る場所によって症状が変わる」ため原因に気付きにくいのが特徴です。この記事では、Anycast を自前で運用している場合と、Anycast で動く CDN・DNS サービスを利用している場合のそれぞれで起きやすいトラブルを事例として挙げ、症状・原因・確認方法・対処をまとめます。経路の衝突や ARP の重複など「競合」の切り分けは別の記事で扱っているため、ここでは運用中に表面化しやすい事例に絞っています。
事例を読む前に：拠点を特定する手段を用意する
どの事例でも、最初にやることは「自分の通信がどの拠点に届いているか」の特定です。DNS なら NSID、Web なら拠点名を入れた独自ヘッダーを返すようにしておくと、調査の時間が大きく変わります。
# DNS：応答した拠点の識別子を表示（サーバー側で NSID を有効にしている場合）
dig @192.0.2.53 example.com +nsid
# Web：拠点ごとに付けた独自ヘッダーを見る（ヘッダー名は自分で決めたもの）
curl -sI https://example.com/ | grep -i x-served-by
# 経路と遅延をまとめて見る
mtr -rwc 20 example.com自分の端末からは1つの拠点しか見えないため、RIPE Atlas のような計測基盤や、通信事業者が公開している Looking Glass で、複数の地域から確認できるようにしておくと切り分けが進みます。
事例1：サービスが止まった拠点に通信が流れ続ける
症状：一部の利用者だけがタイムアウトする。自分の環境からは正常に見える。
原因：拠点のアプリケーション（Webサーバーや DNS サーバー）は停止しているのに、ルーターの BGP セッションは生きていて経路の広告が続いている状態です。その拠点に最も近い利用者の通信は、止まったサーバーに吸い込まれます。
確認：問題の利用者がどの拠点に届いているかを特定し、その拠点のサービスに拠点内のユニキャストアドレスから直接アクセスして確かめます。
対処：経路の広告をサービスのヘルスチェックと連動させます。ExaBGP や BIRD、FRRouting と監視スクリプトを組み合わせ、「サービスが応答しなくなったら広告を取り下げる」構成にするのが一般的です。取り下げの判定が敏感すぎると経路が出たり消えたりを繰り返すため、連続失敗回数や復帰までの待ち時間を設けます。
事例2：近いはずの拠点ではなく、遠い拠点に届く
症状：国内の利用者なのに応答が遅い。調べると海外の拠点が応答している。
原因：Anycast の行き先は地理的な距離ではなく、BGP の経路選択で決まります。利用者側の事業者と自分の上流との接続（ピアリング）の都合で、遠い拠点の経路のほうが「良い」と評価されることがあります。
確認：該当する事業者の Looking Glass で自分のプレフィックスの経路を見て、どの拠点経由の経路が選ばれているかを確認します。
対処：遠い拠点側で AS パスのプリペンドを使って経路を不利にする、上流事業者の BGP コミュニティで広告範囲を絞る、国内の接続点を増やす、といった方法があります。どの方法も効果は相手のネットワークの方針次第なので、変更後に複数の地域から再度確認します。
事例3：Let’s Encrypt の HTTP-01 認証が通ったり失敗したりする
症状：複数の拠点で同じドメインを配信している構成で、証明書の発行や更新が不定期に失敗する。
原因：certbot などを実行した拠点に認証用のファイルを置いても、認証局からの確認リクエストは別の拠点に届くことがあります。Let's Encrypt は複数の地点から検証を行うため、拠点ごとにファイルが無い状態だと失敗しやすくなります。
対処：DNS-01 認証に切り替える方法が扱いやすい選択肢です。HTTP-01 を使い続ける場合は、/.well-known/acme-challenge/ へのリクエストを全拠点から1か所の発行用サーバーに転送する設定にします。発行した証明書の配布も、拠点ごとの更新漏れが起きないよう同じ仕組みで管理します。
事例4：大きなページだけ表示が止まる（PMTUD の問題）
症状：小さなレスポンスは返るのに、画像や大きな HTML の途中で通信が止まる。
原因：経路の途中で MTU が小さい区間があると、ルーターは「パケットが大きすぎる」という ICMP を送信元に返します。Anycast では、この ICMP が TCP セッションを持っている拠点とは別の拠点（あるいは同じ拠点内の別サーバー）に届くことがあり、送信側がパケットサイズを下げられずに通信が止まります。
確認：
# 経路上の MTU を調べる
tracepath example.com
# Linux：断片化禁止で 1500 バイト相当のパケットを送る（1472 + ヘッダー 28）
ping -M do -s 1472 -c 3 example.com対処：拠点のルーターやロードバランサーで TCP の MSS を経路の MTU に合わせて調整する（MSS クランプ）方法がよく使われます。
# 転送する TCP の SYN パケットで MSS を経路 MTU に合わせる（iptables の例）
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuファイアウォールの設定を変える前に、現在のルールを iptables-save で保存しておき、遠隔の機器ではコンソール接続など切り戻しの手段を確保してから作業してください。
事例5：CDN 経由にしたら、ログイン制限が全員にかかった
症状：Anycast で動く CDN（Cloudflare など）を WordPress の前に置いたところ、ログイン試行回数の制限やコメントのスパム判定が、関係ない利用者にまで適用される。アクセスログの接続元が CDN のアドレスばかりになっている。
原因：オリジンのサーバーから見ると、接続元は CDN の拠点のアドレスです。実際の訪問者のアドレスはヘッダー（X-Forwarded-For や CDN 独自のヘッダー）に入っているため、それを使わずに判定すると、多数の訪問者が少数のアドレスにまとめて数えられます。
対処：Webサーバー側で、信頼できる CDN のアドレスから来たリクエストに限って、ヘッダーの値を接続元として扱うように設定します。Nginx の例です。
# CDN 事業者が公開しているアドレス範囲に置き換える（例は文書用のアドレス）
set_real_ip_from 203.0.113.0/24;
set_real_ip_from 2001:db8::/32;
real_ip_header X-Forwarded-For;
real_ip_recursive on;Apache では mod_remoteip で同様の設定ができます。set_real_ip_from を広く取りすぎると、誰でもヘッダーを偽装して接続元を詐称できてしまうため、CDN の公開範囲だけを指定し、範囲の更新にも追従します。オリジン側のファイアウォールで CDN からの接続だけを許可している場合も、同じ範囲の更新が必要です。
事例6：監視は正常なのに、利用者から障害の連絡が来る
症状：外形監視は緑のまま、一部地域から「つながらない」という問い合わせが届く。
原因：監視サーバーも Anycast の仕組みに従って特定の1拠点にしか届いていないため、他の拠点の障害が見えていません。
対処：複数の地域から監視する外形監視サービスを使うことに加え、各拠点にユニキャストのアドレス（拠点ごとの管理用アドレス）を用意し、拠点単位でもヘルスチェックを行います。障害が起きたときに「どの拠点か」がすぐ分かるよう、監視結果に拠点名を残しておきます。
変更作業の前に
経路の広告やファイアウォール、CDN の設定は影響範囲が広いため、変更前に設定のバックアップと切り戻し手順を用意し、可能であれば検証環境や影響の小さい拠点で試してから広げます。CDN が公開するアドレス範囲や、認証局・各事業者の運用方針は変わることがあるため、作業時点の公式の案内を確認してください（2026年10月現在）。
まとめ
- Anycast のトラブル調査は、NSID や独自ヘッダーで「どの拠点が応答したか」を特定するところから始めます。
- サービス停止中も経路が出続ける事例は、広告をヘルスチェックと連動させて防ぎます。
- 遠い拠点に届く、PMTUD で大きな通信だけ止まる、といった事例は経路と MTU の確認で切り分けます。
- 拠点ごとに状態を持つもの（ACME の認証ファイル、接続元アドレスによる制限、監視）は、Anycast を前提に設計し直します。