跨境電商賣家用 Clash 穩定管理 Amazon 後台實戰指南

先釐清跨境電商後台的連線需求

跨境電商賣家使用 Clash，重點不是把所有流量一律送進代理，而是讓不同工作流依照目的地、帳號安全與穩定性採取合適的路徑。Amazon Seller Central、Shopify 管理介面、Etsy Shop Manager、物流平台、廣告工具與公司內部系統，可能分布在不同網域與服務商。若所有連線都使用同一個節點，短時間內看似方便，長時間工作卻容易遇到延遲升高、驗證頁反覆出現、後台請求逾時，甚至因出口位置突然變動而觸發帳號安全檢查。

開始設定前，先列出每天真正會使用的服務。Amazon 可能包含 Seller Central、品牌分析、廣告控制台、客服與報表下載；Shopify 可能包含管理後台、Shopify Payments 相關頁面、應用程式管理與 Webhook 測試；Etsy 則常見商店管理、刊登商品、訂單與訊息功能。不同平台的登入網域、靜態資源、圖片 CDN 和第三方工具不一定相同，因此只加入一個首頁網域，並不能保證整個後台都會按照預期分流。

工作類型	常見連線特徵	建議策略	主要檢查項目
商品與訂單管理	HTTPS、請求頻繁、需要穩定登入狀態	固定地區節點	登入持續性、API 回應時間
廣告與報表	頁面較複雜、下載檔案較多	穩定節點或備援組	下載完整性、長連線穩定度
物流與供應商系統	可能是本地服務或企業白名單	直連或獨立策略	公司 IP、內網 DNS、憑證
客服與協作工具	跨多個網域，常有即時通知	依網域規則分流	WebSocket、通知與上傳功能

用規則模式建立電商分流骨架

建議將 Clash 模式設定為 rule，不要長期使用 global。全域模式雖然容易理解，但會讓物流、銀行、公司系統、作業系統更新與電商後台共用同一路徑，發生問題時難以判斷是 DNS、節點還是服務端限制。規則模式可以把 Amazon、Shopify、Etsy、直連服務與其他未分類流量分開處理。

策略組至少可以分成「電商固定出口」、「電商備援」、「直連」與「其他代理」。其中固定出口用於主要後台，備援組只在主節點出現明顯逾時、TLS 連線中斷或長時間無法載入時切換。若使用 url-test，應把測試結果當作參考，而不是讓它每隔幾分鐘自動跳到另一個地區。電商後台更重視工作階段連續性，單純追求最低延遲可能造成出口頻繁變更。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: 電商固定出口
    type: select
    proxies:
      - 店舖主節點
      - 店舖備援
      - DIRECT

  - name: 電商備援
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    proxies:
      - 店舖主節點
      - 店舖備援

rules:
  - DOMAIN-SUFFIX,sellercentral.amazon.com,電商固定出口
  - DOMAIN-SUFFIX,amazon.com,電商固定出口
  - DOMAIN-SUFFIX,shopify.com,電商固定出口
  - DOMAIN-SUFFIX,etsy.com,電商固定出口
  - DOMAIN-SUFFIX,公司內部網域,DIRECT
  - MATCH,DIRECT

上面的網域只是設定骨架，不能直接視為所有平台的完整清單。實際使用時，應從 Clash 日誌觀察瀏覽器載入頁面時產生的網域，再判斷哪些是平台核心服務、哪些是圖片或分析服務。規則由上而下比對，較具體的 DOMAIN-SUFFIX 應放在較寬泛的規則前面；如果最後使用 MATCH,DIRECT，未被明確列入的第三方服務就會直連。

固定出口與備援節點如何取捨

「固定」不代表永遠不能切換，而是正常工作期間維持一致的出口。假設賣家上午使用主節點登入 Amazon，下午主節點故障，才切換至同一地區、同一服務品質的備援節點。切換後不要立刻重複提交付款、退款或廣告修改操作，先重新整理頁面並確認後台狀態，避免因前一個請求實際已完成、瀏覽器卻顯示逾時，而造成重複操作。

主要節點：用於日常登入、商品編輯與訂單處理，優先看穩定度與長連線表現。
備援節點：與主要節點保持相近地區與協定，避免切換時同時改變太多變數。
測試網址：只能測量某個 HTTP 端點，不等於 Amazon、Shopify 或 Etsy 後台一定可用。
直連策略：只放入確認不需代理且可信任的服務，不要為了簡化規則把所有流量設成直連。

動手設定一個可回復的電商工作環境

以下流程適合在 FlClash 或其他採用 mihomo 核心的客戶端中操作。不同客戶端的按鈕名稱可能是「設定檔」「Profiles」「覆寫」或「代理」，但判斷原則相同：先備份、再修改；先以瀏覽器測試，再逐步擴大規則範圍。

備份目前設定：在設定檔頁面匯出正在使用的 YAML，並另外記錄訂閱名稱、混合連接埠、DNS、TUN 狀態與目前策略選擇。訂閱 URL 含有存取權杖，不要貼到公開文件或客服截圖中。
確認核心版本：查看客戶端的核心資訊頁，確認實際執行的是 mihomo 或其他相容核心。若設定使用 rule-providers、TUN 或較新的節點協定，先確認核心能解析相關欄位。
建立最小規則：先只加入主要後台的必要網域，使用 mode: rule，不要一開始就匯入數千條未整理的規則。規則越少，越容易定位錯誤。
設定固定策略：將主節點與備援節點放入同一個選擇組，先手動選定主節點。若客戶端支援健康檢查，可使用 600 秒左右的間隔，避免過度頻繁探測。
清理瀏覽器狀態：只關閉受影響平台的分頁，重新開啟登入頁。不要在問題未定位前同時清除所有 Cookie，否則可能新增多重驗證與裝置確認，讓排查變得更複雜。
逐項驗證功能：依序測試登入、商品列表、單一商品編輯、訂單檢視、報表下載與客服頁面。每完成一項，就查看 Clash 日誌中的命中規則與實際策略。
記錄結果：記下測試時間、使用節點、錯誤碼、命中網域與是否重試成功。這份紀錄比「網頁打不開」更能協助判斷問題位於 DNS、代理連線或平台服務端。

Amazon、Shopify 與 Etsy 的實際分流情境

Amazon 後台的登入與訂單操作

Amazon 後台常同時載入主站、區域化 Seller Central、圖片服務、報表服務與第三方驗證元件。若只為 sellercentral.amazon.com 設定代理，其他必要請求可能走直連，結果是登入頁出現但商品列表、圖片或訂單資料載入失敗。遇到這種情況，先在日誌中查看被拒絕或逾時的網域，再逐條加入規則，不要直接把所有 Amazon 相關網域無條件送入代理。

Amazon 對帳號安全與登入環境變化較敏感。正常使用時應維持固定的作業系統、瀏覽器設定、出口地區與裝置驗證方式。若看到額外驗證、登入通知或風險提示，先停止重複嘗試，確認帳號安全中心、註冊信箱與雙重驗證狀態；不要透過不停更換節點的方式繞過平台檢查。

Shopify 商店後台與第三方應用程式

Shopify 管理介面經常與應用程式、支付、物流、分析及 Webhook 服務互動。主後台能開啟，不代表第三方應用程式的 OAuth 授權或嵌入頁面也能正常使用。測試時應分開確認管理介面、商品儲存、應用程式授權與結帳測試，不要將支付頁面的失敗直接歸因於 Clash。支付或結帳問題還可能來自瀏覽器 Cookie、商店設定、應用程式權限或服務端狀態。

若使用 Shopify CLI、API 工具或本地開發伺服器，系統代理與 TUN 的行為可能不同。命令列程式不一定遵循瀏覽器的代理設定，應先用簡單的 HTTPS 請求檢查連線，並確認環境變數、憑證驗證與本機 Callback 位址沒有被錯誤送入代理。

Etsy 商品刊登與客服訊息

Etsy 的商品刊登通常涉及圖片上傳、描述儲存、庫存更新與訊息通知。若文字頁面正常但圖片上傳卡住，優先查看上傳請求的實際網域、檔案大小與代理日誌。大檔案傳輸對節點穩定度與 MTU 更敏感，未必能用首頁的延遲數值判斷。上傳失敗時不要反覆點擊提交，先確認商品是否已建立或草稿是否已保存。

現象	可能位置	建議順序
登入頁一直重新導向	Cookie、出口變化、驗證網域分流不一致	固定節點、檢查日誌、重新建立工作階段
列表能開但圖片空白	CDN 網域未命中相同策略	查看失敗網域，再補充精確規則
儲存商品提示逾時	節點丟包、長連線中斷或服務端繁忙	等待確認結果，避免重複提交
報表下載檔案損壞	連線中斷、代理重試或瀏覽器快取	重新下載並比較檔案大小與格式

異常排查與日常維護方法

後台連線出問題時，先把「平台故障」「代理故障」「本機瀏覽器故障」分開。可以用同一台裝置、同一個帳號，在不改動多個設定的前提下，分別測試系統代理關閉、主節點、備援節點與另一個網路。每次只改一個變數，才能知道結果是否真的由某項設定造成。

DNS 錯誤：查看核心日誌是否出現解析逾時、SERVFAIL 或 DNS 劫持相關訊息。不要只因瀏覽器顯示空白就直接更換全部 DNS。
連線被重置：比較主節點與備援節點，觀察是否只有某個出口或某種協定發生 connection reset。
403 或額外驗證：先確認平台帳號安全通知與服務規範，不要用大量重試、快速切換節點或偽造請求標頭處理。
部分資源載入失敗：檢查規則命中情況，特別是 CDN、登入授權、圖片、上傳與 WebSocket 網域。
TUN 啟用後全系統異常：先關閉 TUN，恢復系統代理或直連，再檢查虛擬網卡、路由、DNS 劫持與排除清單。

curl -I --connect-timeout 10 --max-time 20 \
  -x http://127.0.0.1:7890 \
  https://example.com

上面的命令只能確認本機代理是否能建立基本 HTTPS 請求，不能證明特定電商帳號或後台功能一定正常。實際測試時，請將 example.com 替換為自己有權存取的公開測試網域，不要把含有登入權杖、Cookie 或訂閱 Token 的請求貼到公開平台。

日常維護可以採取低頻率、可回復的方式：訂閱更新間隔通常設為 6 至 24 小時，規則集依提供者建議更新；每次更新後確認核心仍能載入設定；變更節點或 DNS 前先匯出 YAML；每週檢查一次目前策略是否意外被切回自動選擇。若團隊多人共同操作，應將節點命名、固定出口用途與故障切換步驟寫成簡短文件，避免每個人使用不同的代理策略。