為什麼要用 PAC，而不是直接開「系統代理」？
Clash 圖形客戶端常提供一鍵系統代理：把作業系統層級的 HTTP／HTTPS Proxy 指到本機埠位。好處是許多會讀取系統設定的程式立刻跟著走代理；壞處是您不一定希望每一支程式都跟著改道。例如：公司規定 Outlook 或特定內網工具必須走內部 Proxy；本機 npm、git、容器或虛擬機希望維持直連；或您已依 WSL2 另做終端機環境變數，不想被系統層反覆覆寫。
PAC 則是一份由瀏覽器載入的 JavaScript 規則腳本：對每個請求的 host 決定要 DIRECT 還是送到某個 PROXY。當您只在 Chrome 內指定 PAC，而不更動作業系統的網路設定時，就達成「瀏覽器單獨走 Clash、其他程式維持原狀」的配置邊界。這與開啟 Clash TUN 把整張路由表交給核心完全不同；若您需要的是「僅瀏覽器」，優先考慮 PAC 或瀏覽器內建的手動 Proxy，而不是擴大接管範圍。
前置：確認 Clash 監聽埠與模式
請先在客戶端（如 Clash Verge Rev）確認HTTP 代理埠或 Mixed Port 的實際數字，常見為 7890，但以您介面顯示為準。PAC 若以 PROXY 形式指向 Clash，通常對應接受 HTTP CONNECT的那個埠；若您只開了純 SOCKS，請改在 PAC 中使用 SOCKS5 語法，或改開 Mixed／HTTP 埠，避免瀏覽器握手失敗。
建議 Clash 端維持規則模式，由核心決定各域名走代理或直連；PAC 這一層只負責「把瀏覽器流量送進 Clash」，而不要試圖在 PAC 裡複製整份 GEOIP。若您尚未完成安裝，可先對照 Clash Verge Rev Windows 安裝教學 或 macOS 對應流程，再回來做瀏覽器分離。
小結：本文假設 Clash 已在本機正常監聽；PAC 中的位址請寫 127.0.0.1 與實際埠，與「Allow LAN」無衝突。
1最小可用的 PAC 範例（指向本機 Clash）
將下列內容存成純文字檔，例如 clash-chrome.pac（檔名可自訂）。重點函式為 FindProxyForURL：對單一主機名稱、localhost、以及常見區網位址走直連，其餘一律交給 Clash，由核心的規則再細分。請把 7890 換成您的 HTTP／Mixed 埠。
function FindProxyForURL(url, host) {
if (
isPlainHostName(host) ||
dnsDomainIs(host, "localhost") ||
shExpMatch(host, "*.local") ||
isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
isInNet(dnsResolve(host), "172.16.0.0", "255.240.0.0") ||
isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0") ||
isInNet(dnsResolve(host), "127.0.0.0", "255.0.0.0")
) {
return "DIRECT";
}
return "PROXY 127.0.0.1:7890";
}
若您希望只有特定網域進代理、其他全部直連，也可以反過來寫多組 shExpMatch／dnsDomainIs；但維護成本較高，且容易與 Clash 規則重複。實務上「PAC 全送本機、由 Clash 分流」通常較直覺，只要記得在 Clash 規則裡處理好內網與本機服務（可搭配 fake-ip-filter 與直連規則）。
注意：dnsResolve 在部分環境可能對尚未存在的名稱回傳錯誤；若 PAC 異常，可簡化條件改以 host 比對為主，或改用瀏覽器支援度較穩的寫法。若您不熟 PAC 除錯，寧可先把條件放寬，確認「能進 Clash」再收緊。
2Windows：讓 Chrome 載入 PAC，且不依賴系統 Proxy
在 Windows 上，請先決定 PAC 檔的固定路徑，例如 C:\Users\您的使用者\proxy\clash-chrome.pac。Chrome 接受的 PAC URL 常見寫法為 file:///C:/Users/.../clash-chrome.pac（斜線方向與磁碟代號請依實際路徑調整）。接著擇一方式套用：
- 圖形介面：開啟 Chrome 設定 → 系統 → 開啟您電腦的 Proxy 設定——此路徑可能會帶您到 Windows「Proxy」頁面；若您要完全不改系統，請改用手動啟動參數（下項）。
- 捷徑參數：建立 Chrome 捷徑，在「目標」結尾加上
--proxy-pac-url="file:///C:/路徑/clash-chrome.pac"（路徑需 URL 編碼時請改用簡單英文路徑減少坑）。僅以此捷徑開啟的瀏覽器行程會套用 PAC。
若公司政策允許，也可把 PAC 放在內部靜態伺服器上以 http:// 提供，Chrome 以 --proxy-pac-url=http://... 載入，較易統一發版；請留意 HTTPS 內網憑證信任問題。完成後，請在 Clash連線列表觀察瀏覽活動是否出現，並用線上 IP 查詢頁（僅作驗收）確認出口是否符合預期。
3macOS：與「系統代理」分離的實務作法
macOS 上若將 Proxy 寫進「系統設定 → 網路」，影響範圍往往不只 Safari，部分程式也會跟著讀取。若目標同樣是僅 Chromium 系列走 Clash，建議優先使用應用程式捷徑＋--proxy-pac-url，指向 file:///Users/您的帳號/.../clash-chrome.pac。與 Windows 相同，請確認路徑可被該行程讀取，且 PAC 內的埠與 Clash 一致。
若您已在系統層啟用公司 PAC 或 HTTP Proxy，又希望另一組瀏覽器設定直連或走 Clash，實務上會變成「不同使用者設定檔」或「不同啟動參數的 App 包」分開管理；macOS 的網路位置（Locations）也能在不同場景切換整組設定，但那是整機切換，與「單一 App」仍有邊界差異。更多鑰匙圈與 Helper 權限議題可延伸閱讀 macOS Clash Verge Rev 與鑰匙圈 專文，避免與本文的「瀏覽器 PAC」混淆。
Clash 端建議：關掉「系統代理」或避免雙重寫入
若客戶端同時開啟系統代理又另外在 Chrome 指定 PAC 到本機 Clash，有時仍可行，但容易造成認知混亂：某些情境下您會不確定流量是先經系統 Proxy 還是進 Clash。較乾淨的做法是：Clash 只負責監聽與分流，由瀏覽器 PAC 單向送入；系統 Proxy 欄位維持空白、直連，或保留公司派發的設定而不要再被 Clash 覆寫。
在客戶端設定中，通常可找到「開啟／關閉系統代理」或開機自動套用選項；請依您的辦公規範決定是否允許 Clash 在啟動時修改系統值。若必須完全手動，關閉自動寫入可降低與 IT 政策的摩擦。
驗收與常見現象
- 連線日誌：開啟 Clash 連線或日誌面板，在 Chrome 開啟目標網站時應看到對應域名與策略命中；若完全沒有記錄，代表 PAC 未生效或埠錯誤。
- 與 Secure DNS：Chrome 若啟用「安全 DNS」且繞過本機，可能讓您誤以為「規則沒命中」；排查時可暫時關閉對照，並參考 DNS 防洩漏 一文釐清解析鏈。
- 與擴充功能：廣告封鎖或「Proxy 類」擴充可能改寫連線；驗收時可用無擴充的乾淨設定檔測試。
- 與其他瀏覽器：Edge、Brave、Arc 等 Chromium 系亦可類似使用 PAC URL；Firefox 的設定介面不同，若需單獨分流請改查 Mozilla 的 Proxy 設定路徑。
合規與資安提醒
企業網路與設備常受政策管理；自行繞過監控或存取未授權資源可能違反僱傭契約或當地法規。本文僅在合法授權前提下說明技術選項：若您不確定是否允許本機代理，請先洽資訊部門。相較於強行開啟整機 TUN，瀏覽器 PAC 分離在稽核語意上通常較易說明「僅影響單一應用」，但仍須以公司規範為準。
開源資訊與安裝包取得
Clash 生態的核心與客戶端多為開源專案，行為與授權可於公開倉庫查證。安裝程式建議優先從 本站下載頁 取得；若需提交議題或閱讀原始碼，可另開 GitHub 頁面，與「取得安裝包」分開看待。
結語
若您的訴求是不要動整機網路堆疊，又希望 Chrome 仍能享受 Clash 的規則與策略組，PAC 與系統代理分離是相對溫和、可回滾的做法：作業系統繼續直連或沿用公司 Proxy，瀏覽器則以一份小腳本把流量導向本機核心。相較於到處開 TUN 或強制系統代理，這種邊界更利於與 WSL2、套件管理器、內網工具並存，也比較符合「只改瀏覽器」的直覺。
實務上只要確認埠位、PAC 路徑與啟動方式三者一致，並用連線日誌完成驗收，後續維護成本通常低於反覆切換系統層開關。若您也關心 Microsoft Store 等 UWP 與系統代理的相容性，可併讀 UWP 與 Loopback 排查，與本文場景互補。