中国のインターネット基盤と直近のシステム障害対応3事例（第1回）
はじめに
中国国内のシステム障害は、単なる「アプリが落ちた」という話には留まりません。通信キャリア（固定・モバイル）、DNS、巨大クラウド、決済スーパーアプリ、そして国境をまたぐ通信制御までが密接に絡み合うため、障害の影響範囲が一気に“社会インフラ級”へ拡大しやすいのが特徴です。
本シリーズの初回は、中国のインターネットシステムの全体像を押さえたうえで、2025年に起きた対応事例を3つ取り上げます。いずれも「復旧」だけでなく、原因切り分け、ユーザーへの説明、再発防止まで含めて学びが多いケースになっていると思います。
1. 中国のインターネットシステムを俯瞰してみよう
“大きな国内圏”と“国際接続”の二層構造
中国のネットワークは、国内トラフィックが巨大で、アプリやサービスが国内で完結する設計になりやすい一方、国際接続（海外リージョン、国外SaaS、越境API、国外CDN、証明書・ID基盤など）への依存が残るサービスも少なくありません。
このため、国内では動いているのに「外部とつながらない」だけで業務が止まる、という障害形態がしばしば起こり得ます（後述のTCP/443事例）。
キャリア依存と、DNSが“実質的なゲートウェイ”になる現実
中国では大手キャリアの影響力が大きく、ユーザー体験は「回線品質」だけでなく、ローカルDNS（Local Domain Name System）の挙動に強く左右されます。
DNSが不安定になると、アプリやWebは「サーバが生きていても到達できない」状態になり、体感としては全面障害に見えます。阿里云（Alibaba Cloud）自身も、Local DNSの不安定さが解析異常につながり得る点をFAQで明記しています。
“巨大アプリ＝巨大インフラ”という前提
微信（WeChat）、支付宝（Alipay）などの中国生活にはなくてはならないスーパーアプリは、決済・送金・請求払い・生活サービスの入口であり、障害が起きると金融・商取引・公共サービスといった幅広い範囲に波及します。
そのため、障害対応はSRE的な復旧プロセスに加え、詐欺便乗の抑止（偽SMS等）や補償方針の明確化がセットになります（後述の支付宝事例）。
2. 支付宝「政府補貼」誤適用（2025年1月16日）
詳細
2025年1月16日、支付宝の決済画面で「政府補貼（政府補助）」が誤って表示され、支払いが約20%減免される現象が短時間発生しました。報道では、発生時間帯が14:40〜14:45頃とされています。
初動対応で重要だった点（混乱の抑制）
この種の“割引・補助”系障害は、二次被害として
- SNS拡散による過剰アクセス
- 「後で請求される」不安の増幅
- 便乗詐欺（偽の追い金SMS、偽リンク） が同時発生しやすいのが厄介です。
実際に、当該事象については「追い金する」とする短信（SMS）が出回った一方、支付宝は公式に追款しない（ユーザーに返金・追徴を求めない）旨を説明し、偽メッセージへの注意喚起も行っています。
原因の説明
複数報道では、原因は常規のマーケティング活動の后台（管理画面）でテンプレートを誤設定し、割引の種類や額面を取り違えた、という説明になっています。
このタイプは「コード不具合」よりも、権限・審査・ガードレール不足が根にあることが多いです。
学び
- 割引・補助の“ビジネスルール”はコードより危険 本番に入る設定変更ほど、影響範囲が読みづらい。
- “異常割引”を検知するセーフティネット 取引全体の割引率分布が突然変わる、特定文言（政府補貼）が急増する等、KPIで即時検知できる。
- ユーザーコミュニケーションは金融事故として扱う 追い金の有無、資金安全、詐欺注意を短文で明確化することが、復旧と同じくらい重要。
3. 中国联通（Unicom）ローカルDNS異常（2025年8月12日）
詳細
2025年8月12日夜、中国最大の通信大手である中国联通で主に北京などで联通ユーザーが多数のWebサイトやアプリにアクセスできない状況が発生しました。報道では、SNS上で「多数サイトが開かない」「支払い中に途切れた」等の体験談が広く共有されています。
技術的には「DNSが汚染され、多数ドメインが 127.0.0.2 に解決される」といった指摘が流通しました（これは外部観測ベースで、公式確定ではありません）。
対応のポイント：クラウド側の“切り分け”が速い
この事例で注目すべきは、阿里云側が19:40頃に“联通 local DNS 異常”を監視で検知し、运营商に报障（障害連絡）したと報じられている点です。
さらに、20:48頃に影響が解消したとされています。
つまり、クラウド事業者は「自社障害」ではなく、外部（キャリア）起因の可能性を早期に切り分け、連携窓口へエスカレーションしています。ここが遅れると、ユーザーや顧客はクラウド側を疑い続け、対応リソースが浪費されます。
学び
DNSは、アプリのあらゆる通信の入口です。だからこそ、対策は「DNSを冗長化しているから大丈夫」では不十分で、ユーザーが参照するLocal DNSが壊れるとまとめて倒れます。阿里云のFAQにも、Local DNS不安定が解析異常の原因になり得ることが示されています。
実務的な学びは次の通りです。
- HTTPDNS / DoH / DoT等、“Local DNS回避”の選択肢を準備（特にアプリ）
- 複数キャリア・複数回線で監視し、障害が“キャリア限定”か即断できる状態にする
- 影響がDNSに集中している場合、**静的フェイルセーフ（重要ドメインのバックアップ到達経路）を検討する
4. TCP/443が74分間遮断された“国境側”障害（2025年8月20日）
詳細
2025年8月20日、北京時間でおおむね00:34〜01:48頃までの約74分間、中国と海外の間でHTTPS通信が広範に失敗する事象が観測されました。特に影響が目立ったのが、HTTPSの標準ポートであるTCP 443です。この件は、ネットワーク観測・解析を行う研究者／実務者コミュニティによって解析報告が公開され、当該時間帯に「443で通信が成立しにくくなる」という現象が複数地点から確認された、と整理されています。
（参考：GFW Reportの解析、The Registerなどの報道）
重要なのは「特定企業のサーバが落ちた」というより、国境側（いわゆるGFW周辺）にある通信制御の仕組みが、広い範囲でHTTPS通信の成立を阻害した可能性が高い、という性質です。原因については、テスト・設定ミス・新規装置投入など複数の仮説が語られていますが、現時点で確定はしていません。
専門用語解説
（1）TCPとは
インターネット上で「確実にデータを届ける」ための通信方式です。送った順番の保証や、到達確認を行う仕組みがあるため、Web閲覧やAPI通信の多くがTCPの上に成り立っています。
（2）ポートとは
同じサーバでも、用途ごとに入口を分けるための番号です。
・443：HTTPS（暗号化されたWeb通信）の標準ポート
・80：HTTP（暗号化なし）
HTTPSは現代のWeb・アプリ通信の標準なので、443が止まると影響が極めて大きくなります。
（3）HTTPSとTLS
・HTTPS：ブラウザでURLを開いたときに使われる暗号化通信の方式（見た目はhttps://）
・TLS：HTTPSの暗号化そのものを担う仕組み（証明書の検証、鍵交換など）
つまり「TCPでつながる」→「TLSで暗号通信を確立する」→「HTTPでデータをやりとりする」という順番です。
（4）TCP接続の3-way handshake（スリーウェイ・ハンドシェイク）
TCPは接続の最初に、通常次の3ステップを踏みます。
1. クライアント→サーバ：SYN（接続したい）
2. サーバ→クライアント：SYN+ACK（いいよ）
3. クライアント→サーバ：ACK（接続できた）
この後にTLS（暗号通信の確立）のやりとりが始まります。
（5）RST（リセット）とは
TCPで「この接続は終了（強制終了）」と相手に伝える信号です。RSTを受け取った端末は、OSや通信ライブラリが「相手が切断した」と判断し、接続を落とします。
（6）RST+ACK注入とは（今回の核心）
観測によれば、当該時間帯、TCP 443の接続に対して「偽造されたRST+ACK」が経路上から送り込まれ、通信が強制的に切断される挙動が確認された、とされています。
ここで言う「注入」とは、クライアントでもサーバでもない第三者（多くは通信経路上の装置）が、あたかも通信当事者になりすましたパケットを送り込むことで、両端を誤認させる手法です。
物理断線というより「切れたことにさせる」挙動、と理解するとイメージしやすいです。
症状の典型
RSTで接続が切られるタイプの障害は、現場では次のような形で現れます。
・ブラウザ：ページが開かない、途中で止まる、「接続がリセットされました」系のエラー
・アプリ：ログインできない、APIがタイムアウトする、決済が失敗する
・監視：HTTPステータス（200/500）以前に、TCP接続やTLS確立が失敗する
ポイントは「サーバが落ちた」よりも「接続が成立しない／途中で切れる」ため、初動で原因が掴みにくいことです。さらに、443はほぼ全サービスが使うため、影響が一気に広域化します。
なぜ企業にとって致命的か
国内サービスが元気でも止まる、というあなたの指摘はその通りです。ここでは、運用の現実として“何が詰むのか”を具体化します。
（1）海外リージョンのAPI依存が刺さる
国内のサービスでも、裏側で次に依存していると詰みます。
・認証（SSO、ID基盤、トークン発行）
・決済や不正検知（照会API、決済ゲートウェイ）
・分析・広告（イベント送信、タグ配信）
・配信（国外CDN、機能フラグ、アップデート）
443が止まれば、これらの呼び出しがまとめて失敗し、表面上は「国内は生きてるのに動かない」という状態になります。
（2）運用が海外に寄っていると復旧が遅れる
・海外本社からの監視が見えない
・チケット、通話、CI/CDなどの運用基盤が国外SaaSにある
・証明書更新や鍵管理が海外側にある
つまり「障害対応のための道具」まで巻き込まれるので、対応力そのものが落ちます。
（3）74分でも“後から効く”
短時間で復旧しても次が残ります。
・バッチ処理の失敗（再実行が必要）
・トークン更新が欠落（数時間〜数日後にログイン不具合が噴出）
・監視の盲目化（欠損期間のログ・メトリクスが抜け、原因分析が難航）
・データ整合性の崩れ（注文状態、課金イベント、在庫などがズレる）
復旧後の整合性処理が“本番”になるケースです。
原因は？
この件の原因は確定していません。一般に語られている仮説は主に以下です。
・テスト／試験運用（新しい制御ロジックの検証）
・設定ミス（意図以上に広く適用された）
・新規装置投入や更新（境界装置の変更に伴う不具合）
・意図しない波及（特定目的の制御が443全体に拡張された）
ここで重要なのは原因の断定ではなく、「国境側要因で443が一括で不安定化し得る」というリスクを現実の事例として扱うことです。
学び
- 重要経路は中国国内で完結できる代替を用意する（中国内リージョン、国内CDN、国内監視）
- 外部依存は切り替え可能な構成にする（マルチリージョン、キューイング、リトライとサーキットブレーカ）
- 監視は「HTTP 200」だけでなく、TCP握手やTLS確立まで複数レイヤで計測する
- 仕様上の抜け道を狙うのではなく、“つながらない時間がある”ことを前提に業務継続へ寄せる（復旧後の整合性手順まで含める）
5. 事例に共通する「復旧の型」
今回の3つは性質が異なりますが、対応の骨格は驚くほど似ています。
- 検知：利用者報告に先行できるか（決済KPI、DNS到達率、TCP/TLS成功率）
- 切り分け：自社か、キャリアか、国境か、設定か
- 封じ込め：誤設定の停止、障害ドメインの回避、影響範囲の限定
- 説明：短く、確実に（資金安全、追徴有無、復旧見込み、詐欺注意）
- 再発防止：設定ガードレール、監視の多重化、外部依存の設計見直し
参考
・GFW Report（英語）：
https://gfw.report/blog/gfw_unconditional_rst_20250820/en
・GFW Report（中国語）：
https://gfw.report/blog/gfw_unconditional_rst_20250820/zh
・The Register：
https://www.theregister.com/2025/08/21/china_port_443_block_outage
・TechRadar：
・SDxCentral：
https://www.sdxcentral.com/news/mystery-outage-cuts-china-off-from-global-internet-traffic
・GIGAZINE：
https://gigazine.net/gsc_news/en/20250825-china-gfw-block-all-https/
・Economic Times：