CLOUDFLARE

自動鍵交換の停止と、利用を認めるアルゴリズムの変更は別の操作だ。旧APIを使う運用手順には、その区別が必要になる。

Cloudflareは8月23日01時06分から01時54分（UTC）まで、北米のオリジンとシンガポールのデータセンターを結ぶトラフィックで、一部顧客に5xxエラー増加とタイムアウトが生じた可能性があると発表した。事象は解消済みだが、具体的な公開説明は影響時間帯の終了後に出た。

Cloudflareはアジア太平洋のネットワーク性能問題を公表してから8分36秒後に修正を実施した。しかし事象は監視中のままで、場所、製品、症状、影響母数は示されていない。運用者が確認すべき単位は地域全体ではなく、利用者からCloudflare拠点、オリジンまでの経路である。

Cloudflareは8月4日、Workersに関する二つの独立したインシデントを解決した。一方では、意図せず公開された`Temporal`の時刻が1970年を示した。もう一方では、`nodejs_compat`と新しい互換日付の組み合わせが配備時のアサーションに拒否された。共通原因は公表されていない。重要なのは、コードが動き始める前の許可と、動いた後に得る意味の両方が、プラットフォームのリリースによって変わり得ることである。

Cloudflareは8月3日、Workers Buildsで発生したインシデントを約1時間51分後に解決済みとした。運用上の核心は終了時刻だけではない。15時38分（UTC）にビルドの失敗は止まったものの、ユーザーにはなお遅延が生じ得ると説明され、その後に監視、解決という段階が続いた。ビルド経路の復旧は一つの緑色表示ではなく、エラー停止、待機仕事の処理、成果物の確認、デプロイ結果の照合というチェックポイントで判断すべきである。

Cloudflareは、ロンドンにひもづく専用IPv4 Egress IPを使う顧客が公共インターネットへ到達できない可能性があるとして、Gatewayのインシデントを開設した。2時間17分50秒後に解決済みとなったが、公開記録が実際に証明するのは、調査、特定、修正の実装、監視、解決という状態遷移である。原因や顧客数、トラフィック比率、顧客ごとの復旧時刻は示されていない。運用ステータスを正しく読むには、各段階が示す証拠と示さない証拠を分ける必要がある。

2024年6月27日にCloudflareのパブリックDNSリゾルバー「1.1.1.1」への到達性へ影響した事象は、単一の「BGPハイジャック」では説明できない。AS267613による1.1.1.1/32のオリジン広告と、AS262504からAS1031を経由した1.1.1.0/24の経路リークは、異なる経路、異なる検証限界、異なる制御責任を持つ。本稿は、登録情報やROAを可用性の保証とみなさず、実際に経路を生成、受理、伝播、破棄、監視、撤回できた主体に沿って、ネットワークインフラの説明責任を分析する。

意図した設定変更が小さく、生成後の設定が構文上は正常でも、最後の制約が消えれば経路の輸出権限は大きく広がり得る。Cloudflareが公表したIPv6ルートリークを、ソース、実行中ポリシー、Adj-RIB-Out、外部観測、復旧判断まで連結した証拠管理の問題として検証する。

顧客所有IPアドレスの権限記録が正しくても、その経路がいま広告され、適切なサービスに結び付けられ、インターネットから到達できるとは限らない。2026年2月20日の障害は、BYOIP運用に必要な複数の状態を一貫して管理し、復旧を証明する責任の重さを示した。

2013年3月の攻撃は、外部に開かれたDNS再帰、送信元アドレスの偽装、増幅応答、Anycast、BGPが選ぶピアリング／トランジット経路が連鎖すると、個々には小さく見える設定不備が大規模な外部費用へ変わることを示した。説明責任とは組織名から責任を推定することではなく、各運用者が実際に制御できた箇所と、その修復を裏づける証拠を明らかにすることである。

Cloudflareは7月31日11時51分07秒（UTC）、AnalyticsやDashboard、関連APIに関する軽微な障害を記録した。その後、PagesとWorkersのビルドにも影響が広がり、12時43分57秒に修正の監視へ移行、13時01分59秒に解消した。キャッシュ済みファイルのCDN配信とその他のEdgeセキュリティ機能には影響がなかったと同社は説明している。公開サイトが動く一方で、運用者が観測・変更・再ビルドしにくくなる制御面の障害だった。