AI 工具使用全指南

多數網站的判定很粗略:能建立連線、能回傳內容,就算過關。AI 服務不是。它們在註冊、登入、每一次對話請求上都會做判斷,而且判斷依據不只一個。把這一層想清楚,後面所有「換一條線路就好了」的現象都會變得可以解釋。

出口 IP 的歸屬地與類型

AI 服務收到請求後,第一件事是看這個請求從哪個 IP 出來:歸屬地、所屬電信業者或機房,以及這個 IP 屬於機房位址還是住宅位址。機房 IP 本身不是問題——大量正常的企業出口也是機房 IP——問題在於這個 IP 近期有沒有被密集使用、有沒有異常呼叫紀錄。同一段 IP 在短時間內出現大量註冊或高頻請求,整段 IP 會被降低權重,表現是頁面能打開,但登入介面被攔、驗證碼反覆出現。

這也是為什麼「能打開首頁」和「能正常使用」是兩件事。首頁大多是靜態資源,判定最寬鬆;真正的風控發生在登入介面與對話介面上。拿首頁能不能打開當成線路好壞的判斷標準,基本上等於沒判斷。

地區判定不只看 IP

除了 IP,服務還會參考瀏覽器時區、介面語言、帳號的註冊地與歷史登入地。如果 IP 顯示在美國、系統時區卻是 UTC+8、瀏覽器語言是中文,這幾個訊號疊在一起,風控會傾向認為目前環境與帳號的常用環境不一致。這不一定會立刻限制帳號,但會明顯提高觸發二次驗證的機率。把時區與語言跟出口地區對齊,是成本最低的一步。

長連線與串流輸出對線路的要求

對話類工具的回覆是串流輸出的:一次回答期間,用戶端與伺服器之間要保持連線不中斷,內容一小段一小段推過來,整個過程可能持續幾十秒。這條連線最怕的不是延遲高,而是抖動與封包遺失——延遲穩定但絕對值偏高的線路,用起來是順暢的;延遲很低、卻三不五時封包遺失的線路,表現就是回答寫到一半停住。

所以判斷一條線路合不合適,要分三種用法來看:網頁對話類看穩定性與出口品質,上傳下載類看頻寬,API 呼叫類看延遲與出口固定程度。用同一個標準衡量三類用法,總有一類會覺得不順。

一般代理容易在哪一步失效

• 出口輪換:每次連線換一個出口 IP,登入地在地圖上跳來跳去,帳號環境一直在變。
• 長連線被回收:鏈路上的中間設備對閒置連線有逾時設定,對話還沒結束,連線就先斷了。
• UDP 支援不完整:部分工具預設走基於 UDP 的 HTTP/3,線路不支援時表現為頁面一直轉圈。
• DNS 解析走本地:網域解析到鄰近但連不通的位址,連線根本建立不起來。

註冊與登入是風控最集中的兩個時刻。這兩步順利過了,日常使用的摩擦會小很多;這兩步沒過,後面換多少條線路都覺得不順。把這一步單獨拉出來講,是因為它跟線路的關係比大多數人想的更直接。

註冊前先固定出口

建議在註冊之前就選定一條線路並持續使用,不要一邊註冊一邊切換地區。註冊時的出口 IP 會成為帳號的第一個環境指紋,之後每次登入都會跟它比對。第一次登入就跨洲跳變,是最容易觸發驗證的行為之一。

本服務的註冊只需要使用者名稱與密碼,無需電子郵件地址,填表這一步本身很快;真正需要留意的是註冊時使用的網路環境,以及之後幾天是否保持穩定。

把時區與語言調成一致

走某個地區的線路時,把系統時區調整到該地區的常用時區、瀏覽器語言也跟著調整,能降低觸發驗證的機率。這不是非做不可的動作,但做了之後「登入時反覆要驗證」的情況會少很多。反過來說,IP 在東京、時區在 UTC+8、語言是中文,三個訊號互相矛盾,風控更傾向多問一次。

登入失敗的三種情況要分開看

「登入不了」至少有三種不同的情況,處理方式完全不同:

• 頁面根本打不開:網路層問題。換一條線路,或者換一種線路類型(直連換中轉、中轉換專線)。
• 頁面能打開,點登入後報錯或被反覆要求驗證:風控層問題。通常是這條出口的聲譽被拖低了,換一條出口更乾淨的線路,登出後重新登入。
• 登入成功,過幾分鐘就斷線:工作階段層問題。檢查線路是否頻繁抖動,並確認瀏覽器沒有開啟結束時清除資料之類的設定。

一個帳號盡量收斂在一到兩個地區

同一個帳號今天從日本登入、明天從德國登入,在風控看來和「帳號被多人共用」難以區分。日常使用建議固定一到兩個地區;確實需要換地區時,先登出,換好線路再重新登入,而不是在工作階段中途切換。

本服務不限裝置數,五種平台可以同時連線。多裝置同時使用時,更穩妥的做法是讓所有裝置走同一個地區的線路,而不是每台裝置各連一個國家——後者會讓同一個帳號在幾分鐘內出現多個登入地。

多個帳號之間要隔開

如果確實需要同時使用多個帳號,不要讓它們共用同一條出口。同一個 IP 上登入的帳號容易被關聯在一起,其中一個觸發限制,其餘的可能被一併處理。給每個帳號分配相對固定的出口,是成本很低的一道隔離。

網頁版是大多數人用得最多的形態,也是問題表現最「玄」的地方:頁面能打開、輸入框能打字,就是回答到一半卡住。把一次對話拆開來看,問題會具體很多。

一次對話經過哪些環節

輸入問題後,瀏覽器先帶上工作階段憑證請求對話介面;伺服器端驗證通過後開始串流回傳內容;前端一邊接收一邊渲染。任何一環出問題,使用者看到的都是「卡住了」,但原因完全不同:驗證失敗會立刻報錯,連線建立不起來是一直轉圈,連線中途斷開是內容停在半句。

三種中斷表現對應的原因

• 一直轉圈,沒有第一個字:連線沒有建立起來。常見原因是線路不通、DNS 解析異常,或這條出口被目標服務拒絕。
• 輸出到一半停住:連線在傳輸過程中被斷開。常見於線路抖動,或鏈路上的中間設備逾時回收了閒置連線。
• 回答完整,但送下一條失敗:工作階段憑證過期或被清掉。重新整理頁面重建工作階段即可,不必換線路。

長時間閒置之後要重新整理

對話頁面放著不動十幾分鐘,伺服器端會回收這條連線,這是正常行為,不是線路故障。回來繼續用之前,先重新整理一次頁面重建工作階段,比直接在舊頁面上繼續送訊息更省事——後者經常表現為「訊息送出去了,但一直沒有回應」。

瀏覽器端的幾個開關

• 分頁節能與休眠:背景分頁被凍結後,串流連線會被暫停,回到頁面時內容可能不完整。
• 省流量與壓縮代理:多一層中間層,長連線更容易被截斷,排查時先關掉。
• HTTP/3 與線路的相容性:部分工具預設走基於 UDP 的 HTTP/3。如果線路對 UDP 的支援不完整,表現是載入慢或一直轉圈,可以在用戶端裡關閉 HTTP/3、改走 TCP 再試。
• 廣告封鎖類外掛:少數規則會誤傷對話介面的串流請求,排查時暫時停用一次。

多分頁與並行

同時開著幾個對話頁面,等於同時維持多條長連線。在流量較小的級距下,這些連線會互相排擠頻寬,表現是每個頁面都變慢。需要並行處理時,建議錯開使用,或者換到流量更充裕的級距。月訂閱的三種方案分別是 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB,流量依開通日每月重置,可以先依自己的並行習慣估算。

同一個帳號,網頁版正常、API 卻報錯,是很常見的組合。原因是這兩種用法在伺服器端看來幾乎是兩種不同的用戶端:驗證方式不同、請求特徵不同、限流標準也不同。

驗證方式不同

網頁版靠登入後取得的工作階段憑證,存在瀏覽器的 cookie 裡,使用者不需要感知;API 靠金鑰,放在請求標頭裡,由呼叫方自行保管。金鑰一旦外洩,別人可以用它消耗帳號額度,而風控紀錄會算在帳號頭上。所以金鑰只放在伺服器端的環境變數或金鑰管理裡,不要寫進前端程式碼,也不要提交進程式碼儲存庫。

本服務的註冊與使用不涉及電子郵件地址,但 API 金鑰的保管責任在使用方。這一條與線路無關,卻比線路更容易出狀況。

請求特徵不同

網頁版是少量長連線、單次連線持續時間長;API 是大量短連線、請求頻率高、每次資料量小。這意味著兩類用法對線路的訴求幾乎相反:網頁版怕抖動,API 怕延遲和出口變化。用一條適合看影片的線路去跑 API,不一定能得到更好的結果。

並行與限流

AI 服務通常對 API 有速率限制,依每分鐘請求數或每分鐘處理的文字量計算,超出後回傳 429(請求過多)。多台裝置、多個行程共用同一個出口時,限流是疊加的——每個呼叫方都以為自己只用了很少的額度,加起來就超了。控制並行數、把批次任務錯開時段,通常比換線路更有效。

出口穩定對 API 更重要

很多服務會把 API 呼叫的來源 IP 與帳號的常用登入地做比對。網頁版偶爾換個地區,影響有限;API 每天從不同的 IP 段發請求,更容易被判定為異常,表現為間歇性的 403 或要求重新驗證。給 API 呼叫固定一條出口線路,是這類問題的標準解法。

一個最小可用的呼叫範例

以下是透過本服務發起請求的最小範例。位址、金鑰與連接埠都是佔位值,替換成自己的即可;範例裡沒有出現任何真實的訂閱位址或金鑰。

# 讓目前終端機的所有請求走用戶端提供的本機代理連接埠
export HTTPS_PROXY="http://127.0.0.1:7890"
export HTTP_PROXY="http://127.0.0.1:7890"

# 本機與內網位址直連,不經過代理
export NO_PROXY="localhost,127.0.0.1,.internal"

curl -sS "https://example.com/v1/chat/completions" \
  -H "Authorization: Bearer sk-xxxx" \
  -H "Content-Type: application/json" \
  -d '{"model":"your-model","messages":[{"role":"user","content":"ping"}]}'

連接埠以用戶端介面顯示的實際值為準,不同用戶端的預設連接埠不一樣。範例中的網域與金鑰都是佔位值,不能直接使用。

開發場景的麻煩在於:同一個工具,在瀏覽器裡能用,在終端機裡不一定能用;在終端機裡設定好了,編輯器外掛可能還是走直連。原因是它們各自有獨立的網路堆疊與代理設定,誰也不會自動繼承誰的。

命令列:先分清程式認哪種代理

終端機程式對代理的支援大致分三種:會讀環境變數的(HTTP_PROXY、HTTPS_PROXY、NO_PROXY)、只認自己設定檔的(例如 git 的 http.proxy),以及完全不認代理的。遇到「環境變數明明設了卻沒用」,先確認這個程式屬於哪一種,再決定是改環境變數還是改設定檔。另外注意環境變數的大小寫:部分程式只認大寫形式,部分兩種都認。

只代理該代理的流量

把內網位址、本機位址、私有來源的網域放進 NO_PROXY 白名單,能省掉大量莫名其妙的逾時。常見要放進去的包括 localhost、127.0.0.1 以及內網網域後綴。反過來說,如果某個網域走的是本機 DNS 解析、但存取時需要經過代理,就把它明確加進代理規則裡,而不是指望全域模式兜住。

IDE 外掛與編輯器

程式碼補全類外掛、編輯器內建的 AI 助手,通常由獨立行程發起請求,不跟隨系統代理設定,需要在編輯器自己的設定裡單獨填代理位址,或者讓用戶端以全域模式接管全部流量。判斷方法很直接:瀏覽器裡正常、編輯器裡一直轉圈,基本上就是外掛沒走代理。

如果編輯器同時開著終端機面板,注意那個終端機繼承的是編輯器的環境變數,可能和系統終端機不一致——在系統終端機裡驗證通過的代理設定,在編輯器終端機裡不一定生效。

CI 與容器

• 雲端 CI:跑在服務商自己的網路裡,通常不需要額外代理;需要存取特定資源時,依平台文件設定出口。
• 自建 runner:需要明確設定代理,並且把代理位址當成憑證管理,不要直接寫在流水線檔案裡。
• 容器:Docker 容器預設不繼承主機的代理環境變數,需要在建置或執行時明確傳入。
• 日誌:不要讓流水線印出完整請求標頭,避免金鑰被寫進建置日誌。

容器內的一個設定片段

# 執行時把主機代理傳給容器(位址以本機實際監聽為準)
docker run --rm \
  -e HTTPS_PROXY="http://host.docker.internal:7890" \
  -e NO_PROXY="localhost,127.0.0.1" \
  your-image

Linux 下 host.docker.internal 需要額外對應,或者改用主機在 Docker 網路橋接上的位址;範例連接埠是佔位值,以用戶端實際監聽為準。

把設定收斂到一處

命令列、編輯器、容器三處各配一份代理,最容易出現「改了其中一處,另外兩處還是舊的」。建議把代理位址寫進一份三者都能讀到的設定裡——例如在 shell 啟動腳本中定義變數,編輯器與容器引用同一個值,換線路時只改一處,減少「到底哪一層還留著舊設定」的排查成本。

「封號」和「限流」經常被混為一談,但成因不同:限流是頻率問題,通常會自動恢復;封號或暫時限制是判定問題,需要申訴或等待。先分清是哪一類,再決定動作,能省掉很多無效的換線路嘗試。

限流可能來自三個地方

限流可能來自三處:AI 服務本身的帳號層級限制、出口 IP 的共享限制,以及本服務方案的流量額度。前兩者表現為「請求被拒」,第三者表現為「流量用盡」。判斷方法:同一條出口換一個工具試,如果同樣報錯,問題更可能在出口;換一條出口用同一個帳號試,如果恢復正常,問題就在出口 IP 的聲譽。

出口聲譽是可以累積的

同一條出口用得越久、行為越穩定,它在風控裡的紀錄就越接近正常使用者。頻繁更換線路,反而讓帳號的環境一直處在變化中。這也是為什麼固定一到兩條線路長期使用,通常比「哪條快就用哪條」更穩——後者每次都在給風控提供新的比對樣本。

出問題之後的處理順序

1. 先分層

   確認是網路層(連不上)、風控層(能連上但被拒),還是工作階段層(連上了但中斷)。

2. 網路層的動作

   換線路類型:直連換中轉、中轉換專線;或者先關閉 HTTP/3、改走 TCP 再試一次。

3. 風控層的動作

   換到一條出口更乾淨的線路,登出後重新登入。不要在短時間內反覆快速重試——密集嘗試本身會被記為異常。

4. 工作階段層的動作

   重新整理頁面重建工作階段,檢查瀏覽器是否在關閉時清除資料,確認線路沒有頻繁抖動。

5. 帳號層的動作

   如果確認是帳號本身被限制,只能走服務方的申訴管道。此時換線路不會解決問題,但可以把出口固定下來,避免申訴期間環境繼續變化。

不要把換 IP 當成萬用解法

大多數所謂「IP 被封鎖」的情況,其實是這條出口的聲譽被拖低,換一條乾淨線路就能恢復;但如果帳號本身已經進入限制狀態,換出口只是換一個同樣被拒的位置。判斷順序永遠是先分層、再動手,而不是先換線路再看效果。

不同類型的 AI 工具,對網路的訴求不一樣。用同一套標準去選,總會有一類用得不順。以下依使用形態分成幾類,列出關注點與對應的線路類型;線路的完整清單在線路列表頁,可以逐條核對。

三種線路類型的差別

本服務的線路依接入方式分為三類,適合的場景不一樣:

選線順序:先看形態,再看地區,最後看級距

順序建議是:先依使用形態確定線路類型,再依工具支援的地區確定出口位置,最後依每月用量確定方案級距。地區這一層不要憑感覺選——同一個工具在不同地區的可用狀態可能不同,先確認工具支援哪些地區,再從本服務的線路列表裡挑對應的出口。

級距這一層看用量。月訂閱三種方案:¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB,流量依開通日每月重置,中途升級的差價會折算成剩餘天數。如果用量集中在某幾個月、平時用得不多,流量包更合適:¥158/300GB、¥358/1000GB、¥658/3000GB,用完為止、永久不過期。兩種方式都支援支付寶、微信、USDT 付款,並且適用 14 天無條件退款。

在覆蓋範圍上,本服務目前提供 120+ 國家 / 190+ 線路,不限裝置數,五種平台可同時連線。裝置多、並行高時,更容易成為瓶頸的是流量額度,而不是線路本身。

這一章是查表用的。找到最接近的症狀,依序操作,每一步之後停下來試一次——不要一次改五個設定,那樣即使恢復了,也不知道是哪一步起的作用。

症狀:工具首頁打不開

1. 確認用戶端已連線,並且目前線路的地區與目標工具支援的地區一致。
2. 換一條同地區的線路(專線換中轉,或反過來),排除單條線路的問題。
3. 關閉 HTTP/3 或 QUIC,強制走 TCP 再試。
4. 檢查系統 DNS 是否被本地網路接管,必要時改用手動指定的 DNS。
5. 用一個普通網頁確認線路本身能上網,把「線路不通」和「目標工具不通」分開。

症狀:頁面能打開,登入被拒或反覆驗證

1. 登出目前的登入狀態,換一條出口更乾淨的線路,再重新登入。
2. 把系統時區與瀏覽器語言調整到與出口地區一致。
3. 不要在短時間內反覆快速重試,密集嘗試會被記為異常。
4. 如果同一出口下其他工具也異常,優先換線路;如果只有這一個工具異常,問題更可能在帳號端。

症狀:回答輸出到一半停住

1. 重新整理頁面重建工作階段,重送一次,確認是不是偶發。
2. 如果反覆出現,換一條專線類線路。
3. 關閉瀏覽器節能與分頁休眠,並暫時停用廣告封鎖外掛。
4. 檢查是否同時開著多個對話頁面或大流量下載,錯開使用。

症狀:速度忽快忽慢

1. 換一條同地區的線路對比,判斷是線路問題還是目標服務正處於忙碌時段。
2. 避開本地網路的尖峰時段——同一個網路下其他裝置在下載,會明顯影響體驗。
3. 跨洲線路在晚間的波動通常比亞洲區內線路更明顯,重要任務盡量安排在穩定時段。

症狀:只有某個工具不通

1. 換到該工具支援的其他地區線路。
2. 確認該工具是不是走獨立網路堆疊(編輯器外掛、命令列工具),如果是,單獨給它設定代理。
3. 換一條線路仍然不通、而網頁版正常時,優先懷疑工具本身或帳號端,而不是繼續換線路。

症狀:多裝置同時使用時不穩

1. 確認方案的流量級距能涵蓋同時使用量。流量依開通日每月重置,用量可以在使用者面板的帳戶總覽裡查看。
2. 讓所有裝置走同一地區的線路,減少帳號環境的跳變。
3. 把大流量任務(下載、素材上傳)與長連線任務(對話)錯開時段。

以下是這一頁被問得最多的幾個問題。如果還有沒涵蓋到的場景,可以先到說明中心依分類查找,或者從使用者面板提交工單。

接下來可以看什麼

本頁負責把每個環節說透,不負責帶你走一遍流程。如果還沒安裝用戶端、還沒匯入訂閱,先看教學頁的主線;需要核對具體地區和線路,去線路列表;需要核對價格與退款條款,去方案頁。