AI Relay 服務如何有效降低封號率
Wokey Team · 2026-06-27
模型廠商最近進行了一波大規模封號，範圍之廣，連正常使用的個人使用者都被波及。
如果你在經營 Relay 服務，或正在挑選 Relay，這件事值得認真想一想：封號是運氣問題，還是架構問題？
我的答案是後者。封號率不是隨機的，而是由架構決定。
先把視角拉遠。廠商在判斷一個帳號是否被共用或轉售時，通常會看這些訊號：
- IP 變化與 IP 類型 — 你的請求突然從住宅 IP 跳到資料中心 IP，或在不同地理位置之間跳來跳去。
- 行為異常 — 呼叫頻率、並行數和時間分布，明顯不像是一個人在用。
- 多個帳號共用出口 — 幾十個帳號的請求都從同一批 IP 出去。
- 用戶端指紋異常 — 請求標頭、TLS 指紋和裝置特徵與正常用戶端不符。
這些訊號疊在一起，廠商的風控系統就會把你的帳號標記出來。
但如果問哪個訊號權重最大、最容易被偵測到——我會說是 IP。
原因很簡單：IP 是最外層、成本最低的篩選條件。來自住宅 IP 和來自資料中心 IP 的請求，在風控系統眼中屬於完全不同的風險等級。資料中心 ASN + IP 跳動 + 地理位置異常——這三者一旦同時出現，幾乎就是在告訴風控系統「這不是正常使用者」。
老實說，傳統 Relay 服務的架構正好踩在這顆地雷上：所有請求都從 Relay 的伺服器出去，幾十個帳號共用同一批資料中心 IP。不管你怎麼做負載平衡、怎麼輪換代理池，出口本質上就是機房。我看過其他 Relay 業者的方案——代理輪換得很勤快，但查一下 ASN，全是雲端業者。換了面具，臉還是同一張。
所以有些人換了三家 Relay，每一家都是兩週被封一次——不是運氣差，而是每一家的架構都一樣。
那要怎麼讓 IP 保持不變？
如果你是個人使用者，已經有一套成熟的做法：在家裡的 NAS 上部署 New API、One API 這類統一閘道，或使用 sam-to-API 之類的工具，讓所有廠商的 API 都經過它。你的手機、筆電、任何呼叫模型的用戶端，都不直接連到廠商，而是先經過家裡的裝置，再由它轉送到廠商的 API。這樣不管你呼叫哪個模型，從廠商的角度看，出口 IP 永遠是你家寬頻的 IP——和你坐在家裡正常使用沒有任何區別。
出門在外怎麼辦？用 Tailscale 或 WireGuard 這類組網工具，先把手機或筆電的流量導回家裡的 NAS，再從家裡出去。不管你在咖啡廳、辦公室還是火車上，請求都還是從家裡的寬頻出去。廠商不會因為你切換了 Wi-Fi 或開了行動數據，就看到你的 IP 在跳。
這套做法在 fnOS 社群和 AI 自架圈已經相當成熟，教學和實踐者都很多。對個人使用者來說，這是目前最可靠的固定 IP 方案。
但這只解決了一個人的問題。
一個 Relay 服務管理著幾十甚至上百個供應方的帳號。你不可能到每個人家裡去裝 NAS、設定閘道。你需要一套系統化的方案，讓每個供應方安裝一個輕量節點並連上平台——請求仍然從供應方自己的網路出去，但訂單分配和流量路由由平台統一處理。
這種架構叫做供應方端出口——請求從供應方自己的網路出去，而不是從 Relay 的伺服器出去。
打個比方：NAS 方案像是自己在路邊開店——你從家裡出貨，進貨、選品、接單全部自己來。Provider Node 則像是加盟一個平台——你還是從家裡出貨，但訂單由平台派給你。出貨地址沒變，變的是誰在派單。
這就是 Wokey Provider Node 在做的事。
安裝很簡單——一行指令，支援 macOS、Linux、Windows 和 Docker。安裝後開啟本機主控台，綁定你的 Wokey 帳號，匯入你本機的訂閱憑證。節點啟動後，會和 Wokey 平台維持一條 WebSocket 連線。平台把使用者的請求推過來，節點在本機向廠商 API 發出請求。整個過程都從供應方自己的 IP 出去——對廠商來說，這和供應方正常使用自己的訂閱完全一樣。
目前支援的廠商包括 OpenAI/Codex、Anthropic/Claude、智譜、Kimi、DeepSeek、Gemini、xAI 等。
我自己跑過這套架構後，最直觀的感受是：它不是在「對抗」風控——而是根本不會觸發風控偵測的前提條件。從廠商的角度看，這就是一個在家用自己訂閱的普通使用者，沒有任何需要解釋的異常。
整個專案以 Apache-2.0 授權開源，出口白名單直接寫死在原始碼裡。它的安全不是因為我這麼說——而是因為每一行程式碼都可以稽核。
當然，我不會說供應方端出口能保證零封號。IP 只是封號因素之一——呼叫頻率、並行模式和時間分布也可能觸發風控。沒有任何方案能保證零封號率。
但邏輯很清楚：如果你沒處理最大的那個訊號，其他所有最佳化都是蓋在沙子上的房子。
降低封號率的關鍵，是讓你的使用和正常使用沒有區別。保持 IP 不變是最關鍵的一環。個人使用者有個人的方案；Relay 服務則需要系統化的供應方端出口方案。
當 Relay 的競爭走到終局，比的不會是誰的模型多、誰的價格低——而是誰的架構能讓廠商看不出你是 Relay。你現在用的服務，請求是從誰的網路出去的？