為什麼不能沿用「ChatGPT／Claude 那一套」規則？

許多使用者在整理 Clash 規則時，已經習慣把大型語言模型的網頁與 API 收斂到單一 AI_PROXY。這對純瀏覽器或 IDE 外掛場景通常夠用，但Adobe Creative Cloud 與 Firefly 相關流量並不是同一張主機地圖：身份驗證大量經過 Adobe IMS（常見於 adobelogin.com 體系）、產品功能與雲端同步則分散在 adobe.io 底下的眾多微服務、而行銷入口、說明文件與靜態資源又可能落在 adobe.com 與 CDN。若只用過寬的 DOMAIN-KEYWORD 或與其他雲端服務共用的寬鬆後綴，輕則誤傷無關站點，重則出現「網頁能開、Creative Cloud 桌面程式卻一直轉圈」這種最難排查的半套連線。

實務上較穩的做法，是另建 ADOBE_CLOUD_PROXY（名稱可自訂），把與登入、授權交換、雲端面板與 Firefly 助手相關的主機，用明確的 DOMAIN／DOMAIN-SUFFIX 放在 GEOIP、大型 RULE-SET 與 MATCH 之前。這樣您可以在日誌裡快速分辨「是 IMS 走錯出口」還是「某條 adobe.io API 仍落在直連」。若尚未完成訂閱匯入，建議先完成 訂閱匯入教學，再回頭調整規則，避免策略群組內的節點名稱與實際訂閱不一致。

典型症狀：登入、同步與 Firefly 助手分開看

在受限或高延遲網路環境中，Adobe 桌面生態常見的問題並非單一「斷線」，而是鏈路某一環逾時卻沒有明確錯誤碼。下面三類症狀對應的 DNS 與規則檢查重心不同，建議先分類再動手改設定，可省下大量試錯時間。

身份驗證與帳戶面板

• 瀏覽器登入頁長時間空白或轉圈：多與 IMS、OAuth 回呼、企業 SSO 閘道有關；若只有瀏覽器走代理、系統層解析卻繞過本機，也可能出現表單載入一半就停住。
• 已登入卻反覆要求重新驗證：常見於登入旅程與主要 API 請求長期分裂在不同出口 IP，觸發風控或工作階段不一致；此時比起再加寬規則，不如先固定節點做對照測試。

Creative Cloud 桌面程式與同步

• 雲端文件／字型庫同步卡住：實際流量常落在 adobe.io 的特定子網域與資產 CDN；若規則過寬導致命中順序錯誤，會變成「小檔案能傳、大封包或長連線一直重試」。
• 應用程式內建商店或更新檢查失敗：除了代理規則，也要同步檢查是否啟用 TUN、以及防火牆是否攔截 UDP／QUIC；可與 TUN 模式指南對照，先確認流量有進入核心再談規則命中。

Firefly 與雲端助手類功能

• 面板開啟後助手回應逾時、或產生式步驟停在第一步：這類功能往往依賴多段 REST／WebSocket 與分析上報；任何一段落在直連或被錯誤規則提前帶往不適合的節點，外在表現都是「像壞掉一樣轉圈」。
• 與通用 LLM 網頁分流的差異：Firefly 與 Creative Cloud 深度綁定授權與資產索引，主機集合與 ChatGPT／Claude 分流專文中的 OpenAI／Anthropic 網域互不替代；請勿以為開啟同一組「AI 規則」即可覆蓋。

主機地圖：IMS、adobe.io 與創意雲入口

以下分類用於建立規則時的心智模型，不是保證永不變更的官方清單。Adobe 會調整微服務邊界、CDN 與區域化端點，最可靠的補強方式仍是開啟連線日誌，找出仍落在 DIRECT 或被寬鬆規則提前命中的主機名稱，再往回補 DOMAIN 或更精準的 DOMAIN-SUFFIX。

身份驗證（Adobe IMS）

• 登入與權杖交換：常見後綴包含 adobelogin.com；實務上會看到區域化或叢集前綴（例如 ims-na1.adobelogin.com 這類模式）。建議以日誌為準逐步補齊，而不是一次寫死過多猜測性子網域。
• 服務發現與聯邦登入：企業帳戶可能另走 IdP 網域；若您環境含 SSO，請把企業 IdP 與 Adobe IMS 一併納入同一策略思路，避免登入回呼被帶往不同出口。

雲端 API 與同步（adobe.io 家族）

• 微服務與控制平面：許多功能請求落在 *.adobe.io；直接用一條超大的 DOMAIN-SUFFIX,adobe.io 往往過寬，容易與其他非桌面創意場景的 Adobe 流量混在一起。教學上可先放寬驗證，確認症狀消失後，再依日誌縮成較精準的子網域集合。
• 常見關鍵字（僅供對照日誌）：例如雲端資產與協作相關主機常出現 cc-api-data.adobe.io、cc-collab.adobe.io、lcs-cops.adobe.io 這類名稱模式；實際清單請以您客戶端版本與地區為準。

入口網站、說明與 Firefly 產品頁

• 行銷與說明：www.adobe.com、helpx.adobe.com 等；這類流量有時直連即可，但若與登入轉址鏈混在一起，仍可能需要在過渡期內暫時與 IMS 共用同一策略群組做對照。
• Firefly 與雲端創意入口：產品線會使用多個子網域承載前端與設定；若您只看到「首屏能開、互動元件載入失敗」，請優先查瀏覽器開發者工具或 Clash 日誌中被阻擋或逾時的具體主機名稱。

規則順序：為什麼「抄了 DOMAIN-SUFFIX 仍沒用」？

在 mode: rule 下，rules: 由頂端向下比對，命中即停。因此兩件事必須同時成立：第一，Adobe 相關規則要出現在會「提早結束」的寬鬆規則之前；第二，您要清楚訂閱商插入的 RULE-SET 是否在您自訂規則之前就已把流量帶走。整體分流哲學可與 規則分流深度文一起讀：該文處理 GEOIP、rule-providers 與骨架排序；本篇把同一套「越具體越靠前」原則，收斂到 Adobe 創意雲與身份驗證主機。

若您使用圖形化前端合併多份訂閱，請特別留意「自訂規則插入點」：在檔案底部新增的片段，若載入順序上仍位於某個巨大規則集之後，可能形同沒寫。此時應改為在合併後的專用區段插入，或暫時停用可疑規則集做二分法驗證。

規則清單骨架（請以日誌補齊）

下列條目為教學用骨架，請視環境增刪。優先使用 DOMAIN 或夠精準的 DOMAIN-SUFFIX，避免過大的關鍵字規則誤傷無關站點。命名上建議統一走 ADOBE_CLOUD_PROXY，與其他產品線策略群組分離，方便在日誌中過濾。

• DOMAIN-SUFFIX,adobelogin.com,ADOBE_CLOUD_PROXY（IMS 登入鏈路；若與其他 Adobe 網頁分流策略衝突，請以「登入一致性」優先權衡）
• DOMAIN-SUFFIX,adobe.io,ADOBE_CLOUD_PROXY（偏寬；確認無副作用後，再改為多條更細的子網域）
• DOMAIN-SUFFIX,adobe.com,ADOBE_CLOUD_PROXY（可選；範圍大，建議僅在明確需要時啟用，或改為只含實際日誌出現的子網域）
• 精準補洞：對日誌中反覆出現的單一主機使用 DOMAIN,host.example.com,ADOBE_CLOUD_PROXY，通常比再加一條巨大後綴更安全。

若您使用第三方規則集，請先確認其中是否已含上述網域；重複規則通常無害，但順序與來源衝突會讓除錯變困難。寧可在日誌中確認實際命中來源，再決定要覆寫或關閉某段訂閱規則。

策略群組設計：固定出口與備援

Creative Cloud 與雲端助手除了延遲，還受帳戶地區、授權類型與風控影響。實務上常見做法是：在 ADOBE_CLOUD_PROXY 內放一個 select 讓您手動固定美西、美東或新加坡等節點，另用 url-test 子群組做備援；當桌面程式頻繁出現授權錯誤或 API 回傳地區相關訊息時，先換節點再換規則，可省下大量時間。

若節點本身會輪換出口 IP，也可能導致 Adobe 端視為環境跳動。此時比起盲目加規則，不如在策略群組中暫時固定單一節點做對照測試；確認穩定後再恢復自動測速或負載均衡。

YAML 範例：插入位置與命名

下列骨架示範在 GEOIP 與 MATCH 之前插入 Adobe 相關規則。遠端 URL、節點顯示名稱請替換為您訂閱中的真實值，勿未審核即複製為生產設定：

YAMLproxy-groups:
  - name: "ADOBE_CLOUD_PROXY"
    type: select
    proxies:
      - "ADOBE_AUTO"
      - "Your-Hand-Picked-Node"
      - DIRECT
  - name: "ADOBE_AUTO"
    type: url-test
    proxies:
      # Inject real proxy names from your subscription
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # Adobe IMS + cloud APIs (place BEFORE broad RULE-SET / MATCH)
  - DOMAIN-SUFFIX,adobelogin.com,ADOBE_CLOUD_PROXY
  - DOMAIN-SUFFIX,adobe.io,ADOBE_CLOUD_PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

重點仍是：任何會提前結束比對的寬鬆集合（含第三方 RULE-SET）若放在上述片段之前，您新增的 Adobe 規則可能永遠輪不到。若遇此情況，請改為在訂閱合併後的「自訂規則區」插入，或調整 rule-providers 的優先級與插入點（視您使用的前端而定）。

DNS 與 fake-ip：桌面程式最常忽略的一環

啟用 enhanced-mode: fake-ip 時，規則匹配與應用程式實際解析路徑可能出現落差。當您看到「瀏覽器登入成功、Creative Cloud 卻顯示離線」時，請同步檢查：fake-ip-filter 是否讓某些 Adobe 主機改走不同解析策略、以及作業系統或瀏覽器是否另啟安全 DNS／DoH 繞過本機。

處理原則與其他分流文相同：把 DNS 決策與規則設計放在同一個心智模型裡。必要時針對特定網域調整解析模式、暫時降低日誌等級觀察解析鏈，或在受控環境關閉瀏覽器 DoH 做 A／B 測試。若您同時啟用公司 VPN 或系統級「內容過濾」，也要確認是否與 Clash 的 DNS 劫持範圍重疊。

驗證步驟：建議照順序做

1. 確認模式：客戶端為 Rule，且系統代理或 TUN 已按平台正確授權。
2. 從 IMS 開始：在瀏覽器完成一次完整登入與登出，對照日誌是否命中 ADOBE_CLOUD_PROXY。
3. 開 Creative Cloud 桌面程式：觀察同步、字型與雲端文件是否仍卡住；同步時記錄新出現的 adobe.io 子網域。
4. 再測 Firefly 或雲端助手入口：分開網頁與內嵌面板兩種路徑，避免把兩種不同技術棧的逾時混成同一原因。
5. 固定節點對照：在 ADOBE_CLOUD_PROXY 內改為單一節點，排除自動測速誤判。
6. 檢查寬鬆規則：暫時停用可疑 RULE-SET 或將 Adobe 規則移到更前段，確認命中是否恢復預期。

常見踩坑（多數仍是順序與解析）

• 過大的 adobe.com 規則：一條後綴匹配涵蓋面極廣，除錯與風險都會放大；優先精準到日誌中實際出現的子網域。
• 只配網頁、忘記桌面程式 API：結果是「瀏覽器一切正常、Creative Cloud 永遠顯示需要連線」。
• 以為 MATCH 會幫您「智慧選路」：MATCH 只是兜底命中，並不會自動理解 Firefly。
• 忽略第三方規則集插入點：您在檔案底部新增的規則，若載入順序上仍在某個巨大規則集之後，可能形同沒寫。
• 把問題誤判成節點壞掉：實際為 DNS 或 IMS 出口分裂；先對照日誌再換訂閱。

結語

2026 年前後圍繞 Firefly AI 助手與跨 Creative Cloud 雲端能力的討論很多，但對終端使用者而言，最痛的往往是登入轉圈、同步停滯與助手逾時這類「看起來像軟體掉線、其實是網路鏈路沒對齊」的問題。Clash 能提供的價值，是把 Adobe IMS、adobe.io 與主要創意雲網域變成可排序、可觀測、可回滾的規則與策略群組，而不是一句「開全域就好」。當您用精準的 DOMAIN／DOMAIN-SUFFIX 把主機收斂到 ADOBE_CLOUD_PROXY、把順序放在寬鬆規則之前，並用固定節點與日誌完成驗證時，穩定度通常會明顯好於只依賴泛用 AI 或泛用「國內外分流」規則集。

相較於零散工具拼裝，在同一套規則語意下維護桌面創意軟體與一般上網流量，長期成本通常更低；若您尚未安裝合適版本，建議先從本站下載頁取得對應平台用戶端，並搭配 教學文件完成基礎設定。