为什么还要「分离」而不是直接开客户端里的系统代理
绝大部分 Clash 系图形外壳都提供设置为系统代理：TUN 更会尝试接管整张网卡的访问路径。对用户来说是一键省事，但如果你处在公司网络策略下，常见问题包括：UWP 应用的 Loopback、SSH/npm 走错出口、只对浏览器需要的站点却牵动全机。WSL / 虚拟机不继承宿主「设置里的代理」，反例见 WSL2 与宿主机端口；UWP 侧还有 Loopback 单独一套故事。结论是：把「给谁走 Clash」收束到 Chromium 这一条链路上，很多环境里的排错半径会立竿见影地缩小。
PAC（Proxy Auto-Configuration）是一套由 JavaScript 函数 FindProxyForURL 描述「对不同主机名返回 DIRECT 还是 PROXY」的机制。它可以挂在操作系统（影响所有读取系统配置的软件），也可以只对某次 Chromium 进程通过 --proxy-pac-url 指定。你要的「仅浏览器」，通常对应不显式把整个 OS 设为 Clash PAC，而是只对 Chrome 那一个快捷方式加参数，或对 Chromium 分发策略写明代理模式。
先在 Clash 侧确认本地入站端口
无论你是走 HTTP CONNECT 还是 SOCKS5，浏览器最终要连接到本机的 Clash mixed 端口或拆分的 HTTP/SOCKS 端口。先在客户端里读出实际数值（常见占位如 7890），并确认配置文件里监听在 127.0.0.1 且仅本机使用即可，不必为了一两个标签页就开「允许局域网」——除非你还要给同网段其他机器做透明转发。Windows 全流程可参考 Windows 下的 Clash 安装与端口说明；macOS 若遇到钥匙串或权限弹窗可对照 macOS 系统代理与 Keychain Helper。请本文下面所有占位端口替换成你自己的 mixed 值。
路径 A：--proxy-server（最快，PAC 可先不用）
Chromium支持在不改变系统设置的前提下，仅以当前进程套用代理。做法是复制一份 Chrome 快捷方式，在「目标」字段末尾空格后追加参数（Windows 示意）：
"...\chrome.exe" --proxy-server="http://127.0.0.1:7890"
若你更想用 SOCKS5：--proxy-server="socks5://127.0.0.1:7891"，端口以 Clash 实际为准。用这种专用快捷方式打开的窗口，会与平时双击任务栏图标启动的互不共享配置文件槽位时可以并存，但本质是两份独立会话，记得工作区书签与扩展是否同步到公司策略允许的范围。该方法不涉及 PAC 文件编辑，适合你已经把复杂分流交给 Clash 规则引擎、只想绕开系统层面的场景。
路径 B：.pac 文件仅在浏览器侧加载
当你的诉求是：PAC里写「公司内网后缀全部 DIRECT，少数国际域名再走 PROXY」，而又不想把 PAC 设为 Windows「设置 → 代理 → 自动设置」那条全局链路，可以把 PAC 保存在本地.pac ，再用 Chromium 独占加载。Windows 上常见写法（注意三个斜杠file:///与实际盘符路径）：
"...\chrome.exe" --proxy-pac-url="file:///C:/proxy/clash-only.pac"
macOS 上可以类似地使用 file:///Users/you/proxy/clash-only.pac，路径区分大小写。PAC 内需返回与 Clash listening 匹配的 PROXY 127.0.0.1:端口 或与内核文档一致的 SOCKS5形式。极简示例仅供理解语义（请将端口换成你的mixed或分拆端口）：
function FindProxyForURL(url, host) {
return "PROXY 127.0.0.1:7890; DIRECT";
}
实战中你会把 DIRECT前置给私有网段正则、公司域、国内常用直连域，仅将目标站点交给 PROXY；细粒度仍可依赖 Clash 侧 DOMAIN/GEOIP 规则兜底，PAC 的职责是别把不该进代理的流量先误判进隧道。若你需要把 PAC 托管在局域网 http 服务器上也可用 http:// URL——注意公司内部中间人证书可能对浏览器另有限制。
路径 C：系统级 PAC 但与 Clash 「系统代理」解耦的认知
Windows 若在「网络和 Internet → 代理」中使用使用设置脚本（PAC URL）指向公司内部下发的 pac，再配合不按「使用代理服务器」去填 Clash，那是另一种「整机策略」：它与本文主打「仅用 Chrome 专有快捷方式指向 127」不是同一路径。若在二者之间混杂，容易出现PAC 返回值与 Clash 规则二次叠加的心理负担；排错时请先用浏览器开发者工具的 Network 视图确认哪一层先决策。
Microsoft Edge / Safari / 原生 WebKit
Edge同属 Chromium，可共享同类启动参数。Safari走的是系统网络栈你无法用同一套路「单进程独享 PAC」而不动系统偏好设置；若必须坚持 Safari，只能回到系统代理或网关侧分流，已超出本篇「只对 Chrome」的主线。Firefox在自带「网络设置」里有独立 SOCKS/HTTP/PAC，与 Chromium 的参数体系不一，可参考 Mozilla 文档单独配置。
安全：PAC、本地 mixed 端口与浏览器扩展均能读取或劫持流量。不要从不可信模板复制整段 pac；企业设备上修改启动参数前先确认IT 合规。
关于安装包：客户端获取请优先访问 本站下载页；源码仓库适合做行为核对，不作为首选安装包分发入口。
合规：请遵守所在地法律与公司网络政策；本篇仅描述技术链路，不提供规避监控或违反条款的操作。
小结
Chrome要走Clash，并不等于必须打开系统代理：最短路径往往是专用快捷方式追加 --proxy-server 或 --proxy-pac-url，把你的PAC与分流压力留在本子进程，其它程序继续按公司直连/UWP/WSL各自链路工作。Windows 与macOS的符号细节不同，核心是同源：显式 localhost 与本机监听端口对上。相比整机动一次设置却牵出半屏排错工单，先在单个浏览器配置文件里验证PAC 与端口，再决定是否扩大范围，是许多办公场景里更体面的节奏。
对长期希望「多套场景一键切换」的读者，也可以研究浏览器扩展侧的情景模式（由扩展直接把请求转发到 127.0.0.1），但扩展权限与攻防面与原生启动参数风险评估不同；无论选哪条链路，端口与 PAC 的一致性永远优先于玄学调参。Clash在可观测性与规则可读性上仍能降低维护成本——相比多套独立小工具拼装，统一管理一份 YAML 再接浏览器侧薄配置，经常是更省事的那条路。