交易所 API 可用率怎麼看：失敗請求、事件與測量邊界

可用率回答的是「在指定時間和網路路徑上，被測介面有多少次正常響應」。它不能直接回答你能否順利下單、提現，也不能證明交易所的資產安全。讀這個數字時，觀測範圍和統計規則與百分比同樣重要。

99.8% 是怎樣算出來的

假設某介面有 1,000 次納入統計的請求，其中 998 次成功，2 次失敗，可用率就是 998 ÷ 1,000 × 100% = 99.8%。被明確識別為地域限制並排除的請求不應混入這個分母，排除數量也應單獨檢視。

本站按約 15 秒的間隔探測公開介面；成功需要響應能按該介面預期結構解析，不能只看 HTTP 200。超時、伺服器錯誤和響應內容中的錯誤都可能造成失敗。這個成功率描述請求樣本，不是逐毫秒測量的連續執行時間。

為什麼有失敗，卻沒有事件

本站用連續失敗確認事件：同一介面連續 2 次失敗後開啟，連續 2 次成功後關閉。這樣可以減少一次網路抖動造成的誤報，但也會延遲確認，短暫中斷可能只計入失敗請求，或恰好發生在兩次探測之間而未被看到。

因此，零散失敗會降低可用率，卻不一定形成事件。反過來，事件持續時間是依據探測與確認規則得到的估計，不是交易所每項服務實際中斷的精確起止時間。不要直接把失敗請求數乘以取樣間隔當成宕機時長。

地域限制和網路路徑怎麼影響結果

明確識別的地域限制與一般連線失敗需要分開。HTTP 403 本身不能證明是地域封鎖，也可能與訪問許可權或安全策略有關。本站只按已識別的限制情況分類；不能確定原因時，不應寫成某國家使用者均不可用。

從同一觀測點比較，可以幫助瞭解這條線路上的差異，但使用者所在地區、運營商和連線方式不同，結果也可能不同。採集地點未註明時，延遲資料尤其缺少解釋背景。幾小時樣本與持續數月的樣本，也不應被當成相同強度的證據。

可用率、延遲和業務可用性要分開

介面可能每次都成功返回，但速度很慢。延遲中位數反映較典型的等待時間，p95、p99 用於觀察較慢的一端；它們都要結合統計時段和彙總方式閱讀。僅憑單個極慢請求也不能推斷整個平臺持續擁堵。

本站測量公開行情類介面，未直接測試真實訂單成交、撤單、強平、充值、提現或償付能力。官方狀態頁可能覆蓋不同服務與地區，適合補充核對，而不是與外部探測簡單二選一。

看到異常後如何核對

1. 開啟交易所詳情，檢視觀測時段、樣本量與具體異常介面。
2. 區分零散失敗和已確認事件，檢查是否仍持續。
3. 對照平臺官方狀態頁，核對受影響業務和釋出時間。
4. 確認自己的網路與相關業務狀態；不要把公開介面恢復當作訂單已成功。

從事件記錄檢視探測結果。若主要關心返回的資料是否足夠新，可以繼續閱讀時鐘偏移與行情陳舊度。

規則與資料來源

本文的探測與事件定義來自本站測量方法。Coinbase 官方狀態頁可用於理解平臺如何按服務報告狀態；它不代表其他平臺的規則。本文示意序列不是一次真實事故記錄。