2026-05-18 切換 ProxyMac Mac mini 區域後的 DNS 與 HTTP 用戶端快取：為何 API 仍從舊 POP 出網
你終於把預設 SSH 從租在 東京 的 Mac mini M4 換到 新加坡，或依 代理出口節點模式 輪換 ssh -D SOCKS—可供應商控制台仍顯示 JP 的 POP 回應標頭，延遲直方圖不肯向西移動，QA 堅稱「區域旗標沒翻」。mini 沒有說謊：筆電側的解析器與 HTTP 堆疊仍快取著舊宇宙。 本文交付 (1) 必須證明路徑變更的受眾篩選、(2) 區分 DNS TTL 迷思與溫熱 HTTP/2 池的症狀矩陣、(3) 四層快取蛋糕（作業系統、瀏覽器、語言執行階段、否定 DNS）、(4) 帶數值護欄的九步清理手冊、(5) 可貼上的 curl --resolve 取證、(6) 當 DNS 與 OpenClaw 企業 HTTP_PROXY 不一致時的坑，以及 HTTPSVC 與否定快取陷阱。開單前請先對照 分割 DNS 解析失敗 與 IPv6 Happy Eyeballs。路徑選型見 MTR 區域診斷；規格見 定價頁；SSH 取證模板見 說明中心。
誰必須在變更 ProxyMac 區域後主動清理 DNS 與 HTTP 快取
成功標準包含 HTTP 回應標頭（cf-ray、x-amz-cf-pop、server-timing）、綁定舊邊緣的 TLS 工作階段票證，或 SaaS 管理台依解析路徑推斷的來源國家—而不僅是「SSH 延遲下降」。若你只 ping 過 mini、從未經 SOCKS 或分割隧道 VPN 呼叫公網 API，可略過本文；若你在筆電側對 CDN 或 LLM 邊緣做基準測試而 mini 已遷移，請繼續讀。
- 量化門檻：若
curl -s https://ipinfo.io/json已是新國家，而curl -sI https://api.vendor.example在 10 分鐘內仍列印舊大陸的 POP 碼，屬用戶端快取類問題，而非 ProxyMac 路由缺陷。 - 自動化門檻：重用長生命週期 Node 或 Python 程序的 CI Runner 會繼承程序內 DNS 池；區域輪換後必須顯式回收程序。
- 安全門檻：企業 DNS over HTTPS 描述檔在 VPN 用戶端重新整理政策前可能覆寫你的 mini 遷移—參見 解析器文章。
症狀矩陣：POP 錯誤但 HTTP 200 且 ping「健康」
| 可觀測現象 | 可能層級 | 第一動作 |
|---|---|---|
dig 已是新 AAAA，供應商標頭仍是舊 POP |
HTTP/2 連線池或 TLS 工作階段快取 | 重啟瀏覽器設定檔或單次加 --http1.1 強制新 TCP |
TTL 過期數秒後 dig 仍顯示舊 RRSet |
mDNSResponder / 系統快取 | 在獲准前提下重新整理解析器快取；以 dscacheutil -q host -a name api.vendor.example 驗證 |
| 僅 Java/JVM 服務錯誤；curl 正確 | JVM InetAddress 快取 | 僅在測試 JVM 設 networkaddress.cache.ttl=0；重啟服務 |
| 修正拼字後仍間歇 NXDOMAIN | 否定快取 | 等待否定 TTL 或暫時切換解析器 |
分層蛋糕：系統解析器 vs 瀏覽器 vs 執行階段 vs 連線池
現代堆疊在程序生命週期內會多次解析主機名稱。在 macOS 上，mDNSResponder 依 RR TTL 與平台政策快取肯定與否定答案。Chromium 系瀏覽器再疊一層快取，並在 UDP 路徑存活於區域變更時重用 QUIC 或 HTTP/3 工作階段。Node 的 dns.lookup 除非設定 lookup 掛鉤，否則可能每個池只呼叫一次 getaddrinfo。重用單一 fetch 或 undici 池的 OpenClaw 閘道同樣危險—遷移 mini 後應重啟閘道程序，使出站 TLS 重新綁定到新的解析視圖，尤其與 企業 HTTP_PROXY plist 編碼 聯用時。
curl -v 詳細日誌與 dig +subnet=0.0.0.0/0 輸出—沒有回應標頭證據供應商會駁回「感覺慢」。
九步快取清理手冊
- 基線回應標頭：動 DNS 前對三個供應商端點執行
curl -sI。 - 證明 SSH 路徑：透過 SSH 執行
scutil --get ComputerName確認目標 mini—不要只看提示符號文案。 - 解析器重新整理：在支援的 macOS 版本上執行安全團隊核准的重新整理命令—切勿在工單裡猜測管理員密碼。
- 瀏覽器冷啟動：完全結束 Chromium/Firefox/Safari；關閉一輪「重新打開視窗」。
- SOCKS 重綁：結束舊
ssh -DPID；以lsof -nP -iTCP:1080確認後再開新隧道，參見 SSH 穩定性指南。 - 執行階段回收：在 CI 中重啟 Node、Python 或 JVM Worker—不只是 job 步驟 shell。
- 對照實驗：用下一節的
curl --resolve證明新 IP 段可達供應商邊緣。 - 浸泡：以 2 rps 跑 200 次循序 HTTPS 探測，確認 POP 碼收斂。
- 回滾註記：若重新整理破壞強制入口門戶，依 訪客 Wi-Fi 指南 記錄 VPN 重連順序。
curl --resolve 寫進生產 cron—僅作臨時取證，排障後移除覆寫以免掩蓋未來 DNS 事故。
curl --resolve 與 dscacheutil 配方
若需在未動 /etc/hosts 的情況下繞過陳舊答案，可為單次命令固定權威 IP：
curl -v --resolve api.vendor.example:443:203.0.113.44 https://api.vendor.example/healthz
在 macOS 上與 dscacheutil -q host -a name api.vendor.example 對照使用者態快取當前認知。若 dscacheutil 與 dig @8.8.8.8 不一致，分割隧道 VPN 或 DoH 用戶端仍在 steering—回到 解析器分流。
OpenClaw 與出站 HTTP 用戶端：launchd 背後的快取坑
呼叫模型 API 的 LaunchAgent 常把 單一 undici 或 axios agent 保持數小時。在區域間遷移 mini 後，除非回收事件迴圈 Worker，程序仍可能重用啟動時取得的 DNS 答案。回收時與 HTTP 代理 launchd 文章 中的 NO_PROXY 衛生一致，避免 localhost MCP 流量繼承陳舊的企業解析路徑。
坑：否定快取、SVCB/HTTPS 記錄與 anycast 漂移
NXDOMAIN 會被否定快取—首次拼字錯誤可在數分鐘內毒害自動化。新 HTTPS RR 類型可把用戶端導向與 A 記錄不同的 QUIC 端點；若工具只盯 A/AAAA 會追幽靈。Anycast 前緣在 BGP 切換後仍可能把 TCP 工作階段釘在遠端 POP—只有新連線能證明遷移。
dig api.vendor.example HTTPS +short
常見問題
從 JP 遷到 SG 是否只需等 DNS TTL？權威 TTL 管全球傳播，但筆電仍保留本機快取與溫熱 HTTP 池。應依層清理，而非只等牆鐘 TTL。
為何 curl 已是新區而 Chrome CDN 國家仍舊？堆疊不同：curl 常開新 TCP，而 Chrome 重用綁定舊 anycast 的 HTTP/2 或 QUIC 工作階段。
curl --resolve 能否用於生產冒煙？適合單次命令取證；若寫入自動化且無輪替監控，會掩蓋未來 DNS 事故。
為何 ProxyMac Mac mini 適合作為跨區域快取實驗錨點
租用在 HK / JP / KR / SG / US 的 Mac mini M4 提供可預期的區域出口 IP 段，便於把 POP 標頭與地理關聯；原生 macOS 解析行為與開發者筆電一致；單租戶 CPU 適合長時間 curl 浸泡而無鄰居雜訊。在此驗證快取算術後，可依 定價 透明增加第二台節點，而非在短命 CI IP 上猜測。
