# Idea file：AI 服務被區域阻斷時的排查 playbook

> 這是一份 idea file：只寫目標、方法、約束與驗收標準，不含逐步教學。把它餵給你的 agent，或自己照著走一遍。
> This is an idea file: goal, method, constraints and acceptance criteria. Feed it to your agent, or walk through it yourself.

- 源文章（完整排查紀錄與來源文件）：https://paulkuo.tw/articles/when-ai-chooses-its-users/
- 源文章 raw Markdown：https://paulkuo.tw/articles/when-ai-chooses-its-users.md
- 作者：Paul Kuo（paulkuo.tw）
- 整理日期：2026-10-08。

## 一句話目標

在陌生網路環境（出差、漫遊、飯店 Wi-Fi）遇到 AI 服務突然不可用時，不亂試，用單變數對照把問題定位到正確的層級。

## 核心方法（四步）

1. 先看 HTTP 回應，不先怪自己：`curl -I https://<服務網址>`。若回 302 導向「app-unavailable-in-region」這類頁面，代表是服務端區域判定層主動拒絕，可一次排除 DNS 解析、作業系統、App 當掉、帳號狀態四種假設。
2. 查出口 IP：`curl -L https://ipinfo.io/json`。漫遊時流量出口不一定在你以為的國家。
3. 看出口 IP 的 ASN：若落在雲端機房型 ASN，特徵接近代理流量，可能被服務端納入較高風險的判定。
4. 只改「出口位置」這一個變數（例如換一個 VPN 出口）再測。狀態碼的變化就是答案：302 變成 403 加 `cf-mitigated: challenge`，代表區域層已放行、換 bot 防護接手，是方向正確的訊號。

## 紀律約束

- 每個結論分三種句型講：我觀察到（原始輸出）、我推測（還沒驗證）、我驗證（改單一變數後的結果）。不混用。
- 一次只改一個變數。同時換網路又換裝置，就算通了也不知道為什麼。

## 驗收標準

- 排查結束時，能明確說出阻斷發生在哪一層：服務商區域政策、網路出口路徑、還是 bot 防禦。
- 每個結論都對應到一條可重現的指令輸出。

## 實測案例刻度（2026-07-01，上海虹橋機場）

- 前提：Anthropic 的支援清單不含中國大陸與香港；這是出差途中的排查，不是常駐使用情境。
- 台灣門號國際漫遊，出口 IP 落在香港的雲端機房 ASN（AS153611 CLOUD (HK) LIMITED），claude.ai 回 302 區域不可用。
- 換 VPN 日本出口（只改這一個變數）後變成 403 加 `cf-mitigated: challenge`；瀏覽器過完驗證，Desktop app 一併恢復。

## 延伸結論（為什麼值得做成 playbook）

備援要沿兩條軸思考：模型軸（在中國場景，換另一家美系模型不構成備援，要納入當地可用的模型）與網路出口軸（知道自己每條網路路徑的出口在哪）。

## 刻意不做的事

- 不把繞道當常態方案：那是不穩定、不可依賴的狀態，出差前該準備的是備援。
- 不猜服務端判定的具體依據（GeoIP、ASN、信譽分數的組合，外部無法確認），只記錄可觀察的行為。