一、為什麼 Steam 常「繞過」一般代理設定
Steam 在 Windows 上的主程式、下載 worker、內嵌網頁元件（常見為 steamwebhelper.exe 等）各自發起連線。瀏覽器與少數應用會讀取「系統代理」，但許多原生程式預設直連，或僅對 HTTP(S) 走代理而對其他通訊協定另闢路徑。
因此你會遇到兩種典型現象：一是遊戲下載速度長期偏低、CDN 節點選擇不理想；二是聯機、語音或配對異常，而客戶端介面仍勉強可開。前者多半與下載流量實際走向有關；後者則常牽涉 UDP 與 NAT／防火牆行為，單靠「只代理 443 埠」不一定能覆蓋。
若你已在 訂閱與規則 中為常見網域寫了分流，但日誌裡仍看不到 Steam 相關連線被接管，首先要懷疑的是：流量根本沒進入 Clash，而不是節點品質問題。
二、系統代理、TUN、進程分流三條路
在 Windows 上，常見做法可粗分為三類，彼此可疊加，但解決的問題不同。
- 系統代理：對「會讀系統代理」的程式有效；對 Steam 主程式未必生效。適合瀏覽器、部分開發工具。
- TUN 模式（虛擬網路卡）：在系統層把符合條件的 IP 流量導入核心，較有機會涵蓋不依系統代理的程式與部分 UDP。細節與防火牆、路由表可參考本站 Clash TUN 於 Windows 的排查文。
- 進程分流（PROCESS-NAME 等）：在核心支援的前提下，依行程名稱決定走哪個策略組，適合「鎖定特定 exe」而較少誤傷其他應用。
實務上，許多使用者會採用「TUN 負責廣義接管 + 規則精細分流」；若你希望僅 Steam 走代理、其餘維持直連，則在能取得可靠行程名稱時，進程分流往往比純網域規則更直觀。若你同時在區網內共享代理，亦請一併核對監聽與防火牆，可對照 混合埠與區網共享 一文。
三、進程分流實測：鎖定 Steam 相關行程
為何要指到「行程」而非只寫網域
Steam 使用的主機名與 CDN 範圍會變動，僅依賴靜態清單容易漏網；且同一台電腦上還有瀏覽器、啟動器與其他遊戲，單用 DOMAIN-SUFFIX 可能讓非 Steam 流量誤入同一策略組。以行程名稱為條件，可把「只要是這個程式發起的連線」導向指定出口，較貼近「我只要管 Steam」的直覺。
常見需留意的執行檔（實際以工作管理員為準）
不同版本與語系安裝路徑可能略有差異，實測時請以工作管理員或客戶端日誌中顯示的程式名稱為準。一般會看到：
steam.exe：主程式與部分下載／更新邏輯。steamwebhelper.exe：內嵌網頁與商店介面相關連線。- 部分遊戲本體另有獨立
.exe；若你只代理 Steam 而遊戲仍直連，聯機表現可能與預期不符。
在支援 Mihomo（Clash Meta） 類核心的設定中，常會見到以 PROCESS-NAME（或客戶端圖形介面中的「進程規則」）撰寫的規則，將上述程式指向例如 PROXY 或自訂策略組。撰寫時請注意規則順序：較具體的進程規則應放在寬鬆的 GEOIP 或 MATCH 之前，否則可能永遠匹配不到。
四、UDP 與聯機：市集能開、遊戲內配對失敗？
許多遊戲的語音、配對、P2P 或部分反作弊通道會使用 UDP。若你的環境只穩定處理 TCP（例如部分純系統代理場景），可能出現「網頁與登入正常，一進遊戲就斷線或搜尋不到對戰」的割裂感。
TUN 與核心的 UDP 處理能力，會影響上述流量是否被正確導向節點或按規則分流。不同核心版本與客戶端選項中，可能出現與 UDP 轉發、網路堆疊（stack） 等相關的進階設定；名稱與預設值會隨版本變動，請以你所用版本的官方文件與發行說明為準，本文不替換為固定數值以免過時。
實測時建議分兩段觀察：僅啟動 Steam 與下載時的連線型態，以及進入實際遊戲對局後的 UDP 是否仍由同一套規則覆蓋。若後者失敗，常見方向包括：確認遊戲本體行程是否也需納入規則、是否需調整 TUN 相關選項，或檢查本機與路由器是否阻擋 UDP。
五、規則與策略組：設定思路（非唯一答案）
以下為概念性整理，實際鍵名、縮排與是否支援須以你的核心為準；請勿直接複製到生產環境而不做驗證。
- 策略組拆分：為「Steam 相關」「一般瀏覽」「下載大流量」建立不同
proxy-groups，避免遊戲延遲被長下載拖垮。 - 規則順序：
PROCESS-NAME,steam.exe,Steam-Group這類條目宜置於過寬的國別或最後匹配之前。 - DNS：若使用 fake-ip，請留意日誌中顯示的解析與實際連線是否一致；異常時可先對照 TUN 文排查 DNS 與路由。
若你使用圖形介面客戶端而不手寫 YAML，重點仍是：在介面中啟用進程規則／TUN，並為 Steam 指定策略組與節點。客戶端選型可參考 Clash Verge 與 Clash for Windows 比較，但核心能力與版本更新節奏請以實際發行版為準。
六、實測排查順序建議
建議依序縮小問題範圍，避免同時改動訂閱、節點、TUN 與規則導致無法回溯。
- 確認流量是否進核心：開啟連線日誌，執行一次下載或開啟商店，觀察是否有對應連線紀錄。
- 驗證進程規則是否命中：對照行程名稱與規則順序；未命中時先查模式與核心能力而非先換節點。
- 區分 TCP 與 UDP 現象：若 HTTP(S) 正常而遊戲內異常，優先檢查 UDP 與 TUN 相關設定及遊戲本體行程。
- 最後才調整節點與地區：在路徑已正確的前提下，再比較延遲、丟包與頻寬。
| 現象 | 優先檢查 |
|---|---|
| 日誌幾乎沒有 Steam 連線 | 是否僅依賴系統代理；是否需開啟 TUN 或進程分流；防火牆是否阻擋核心 |
| 下載有速度但遊戲內延遲高／配對失敗 | UDP 是否納入；遊戲 exe 是否在規則內；節點是否適合即時連線 |
| 僅商店可開，下載始終極慢 | Steam 下載區域與 CDN；下載行程是否走代理；是否被錯誤策略組限速 |
七、常見誤區與合規提醒
實務上常見誤區包括：以為「節點越貴越快」卻忽略流量未進代理；或同時開啟多個會改寫系統路由的軟體，導致路由表衝突。建議一次只調整一類設定，並保留可還原的備份。
請遵守你所在地與遊戲服務條款；本文僅討論技術層面的網路路徑與設定思路，不鼓勵任何違反服務條款或法律的使用方式。若你僅需改善家庭網路環境下的連線品質，優先從路由、DNS 與客戶端更新等着手，再考慮代理與分流。
八、小結
在 Windows 上把 Clash 用於 Steam 場景，關鍵是接受一個事實：遊戲平台與瀏覽器不同，未必會乖乖走系統代理。透過進程分流鎖定相關行程，並在需要時以 TUN 與 UDP 設定補齊傳輸層缺口，較有機會同時改善遊戲下載與聯機體驗。相比只堆疊網域規則，這條路更貼近「誰在連線、連線呈現何種型態」的實測邏輯。
相比功能單一、只能切換少數開關的工具，Clash 生態在規則可組合性與核心可替換性上更利於長期維護；把 Steam 與其他用途拆成不同策略組後，日常多半只需微調節點與觀察日誌即可。
若你尚未安裝或希望使用圖形介面更易上手的客戶端，可從本站取得安裝包並匯入訂閱，再依本文順序啟用進程分流與 TUN／UDP 相關選項逐步驗證。