先把概念讲清楚：为什么要这样做
先想清楚两点：一是“一个浏览器进程通常共享同一套代理设置”，二是“要让不同窗口用不同代理，就要让它们看起来像不同的浏览器进程或不同的运行上下文”。换句话说，就是把每个窗口隔离开来，给每个“隔离体”分配单独的代理规则。
为什么单纯在设置里切换不够
- 很多浏览器的代理设置是全局的，切换一次影响所有窗口。
- 扩展能在标签页层面切换，但多数扩展无法做到完全隔离，且受限于浏览器的扩展 API 权限。
- 企业级场景或批量操作时，手动切换效率极低，容易出错。
可选的四种实现路径（从简单到专业）
- 命令行+独立用户数据目录（最直接，对Chromium系非常有效）
- 使用 PAC（Proxy Auto-Config） 文件，按 URL 或端口分配代理
- 系统/第三方路由工具（Proxifier、ProxyCap 等），按进程或端口转发
- 自动化脚本（Selenium、Playwright），编程式批量启动带代理的浏览器上下文
方法对比（简明表格）
| 方法 | 优点 | 缺点 |
| 独立 user-data + –proxy-server | 稳定、窗口级别隔离、易脚本化 | 需要为每个实例指定不同用户目录，磁盘占用增加 |
| PAC 文件 | 灵活按域/端口路由，集中管理 | PAC 逻辑写错会影响全局，调试略麻烦 |
| 系统/第三方路由工具 | 能按进程、端口或应用路由，适合非Chromium应用 | 通常付费，设置复杂，对 HTTPS 处理需注意证书 |
| 自动化脚本（Selenium/Playwright） | 可批量、可编程、适合大量并发窗口 | 需要开发工作，运行环境复杂 |
实操一：基于 Chromium 的命令行启动（适用于比特浏览器若为 Chromium 内核）
思路是：每个窗口用不同的用户数据目录（user-data-dir），同时通过 –proxy-server 参数传入代理。这样系统认为这是不同的浏览器实例，各自独立。
Windows 示例
假设浏览器可执行文件位于 C:\Program Files\BitBrowser\bitbrowser.exe，准备两个不同的配置目录：
- 为第一个窗口创建目录 C:\BBProfiles\profile1
- 为第二个窗口创建目录 C:\BBProfiles\profile2
然后分别用命令行启动：
“C:\Program Files\BitBrowser\bitbrowser.exe” –user-data-dir=”C:\BBProfiles\profile1″ –proxy-server=”socks5://127.0.0.1:1080″
“C:\Program Files\BitBrowser\bitbrowser.exe” –user-data-dir=”C:\BBProfiles\profile2″ –proxy-server=”http://203.0.113.10:3128″
注意：如果浏览器默认会把新窗口合并到已运行进程，请确保 user-data-dir 不同并加上 –new-window（若支持），或直接多次运行可执行文件。
macOS / Linux 示例
macOS（假设应用名为 BitBrowser）可以用：
open -n -a “/Applications/BitBrowser.app” –args –user-data-dir=”/tmp/bb_profile1″ –proxy-server=”socks5://127.0.0.1:1080″
Linux 下直接调用可执行文件：
/opt/bitbrowser/bitbrowser –user-data-dir=”/home/user/.bb_profile1″ –proxy-server=”http://203.0.113.10:3128″
常见问题与解决
- 配置目录权限问题：确保用户对目录有读写权限，否则浏览器会拒绝启动或创建新目录。
- 扩展/插件不会自动安装到新 profile：若需扩展功能，要在该 profile 下手动安装或把扩展复制过去。
- 证书与 HTTPS：若代理为中间人代理（如用于抓包），需要在 profile 中添加信任证书。
实操二：使用 PAC 文件按规则分配代理（适合规则化路由）
PAC 文件是一个 JavaScript 函数 FindProxyForURL(url, host)，返回代理字符串。优点是灵活，可以根据域名、端口甚至时间判断走哪个代理。
示例 PAC（简单版）
下面是一个基础示例（把内容保存为 proxy.pac 并用 –proxy-pac-url=file:///path/proxy.pac 指向它）：
function FindProxyForURL(url, host) { if (shExpMatch(host, \”*.example.com\”)) return \”PROXY 203.0.113.10:3128\”; if (shExpMatch(host, \”*.internal\”)) return \”DIRECT\”; return \”SOCKS5 127.0.0.1:1080\”; }
Chrome/Chromium 启动时可加参数 –proxy-pac-url=”file:///C:/path/proxy.pac” 或在系统代理里指定 PAC URL。
实操三：系统或第三方路由工具（按进程/端口分流）
当浏览器本身不支持进程级代理，或你希望对非 Chromium 应用也生效，第三方工具很有用。工具如 Proxifier（Windows/macOS）、ProxyCap 等可以按进程名、端口、目标地址来路由。
- 优点：不需要修改浏览器启动参数，可对任意应用生效。
- 缺点：通常付费，HTTPS/证书处理需注意，部分高级功能需要熟悉规则写法。
实操四：使用自动化框架批量管理（适合测试或大规模并发）
如果你的目标是同时启动几十、上百个窗口并且每个带不同代理，手动并不现实。这时用 Playwright 或 Selenium 更高效：它们能为每个浏览器上下文设置代理并管理会话。
思路（伪代码）
用 Playwright，大致流程是：创建浏览器 -> 为每个 context 指定代理 -> 在每个 context 中启动页面。优点是可以把 cookie、本地存储等隔离开来。
示例思路：
- 读取代理列表（代理1、代理2、…）
- 循环：为每个代理创建一个 browserContext，传入 proxy 配置
- 在 context 中打开页面并执行自动化任务
一些实用小贴士（经验总结，别跳过）
- 磁盘空间规划：每个 profile 会生成缓存、Cookies 等，长期运行会占明显空间，定期清理。
- 代理健康检查：批量启动前先对代理做可用性检测（连通性、延迟、IP 判定），避免大量无效实例浪费资源。
- 证书和 HTTPS：如果代理对 HTTPS 做中间人，需要在每个 user-data-dir 中导入相应 CA，否则会出现证书错误。
- 并发数控制：浏览器实例很多时，CPU/内存会迅速被消耗，建议限制并发并使用无头模式或精简插件。
- 日志与监控：记录每个窗口对应的代理、profile 路径、启动时间，出现问题时好追溯。
常见故障排查清单
- 窗口仍共享代理：检查是否确实使用了不同的 user-data-dir，或浏览器是否有单实例限制。
- 代理不可用：用 curl 或 telnet 先验证 host:port 可达。
- 页面加载证书错误：确认代理是否做了 HTTPS 解密，是否需要导入 CA 证书。
- 扩展失效或异常：扩展需要在对应 profile 下安装，或有权限限制。
行文到这里，脑子里还有点零散的提示：如果你只是偶尔需要两个不同代理的窗口，手动创建两个 profile 再分别启动就够了；如果要稳定批量运行，先把自动化脚本写好，配一套代理健康检测和日志体系，会省很多后续维护时间。嗯，别忘了测试环境先试小规模，确认代理策略、证书和磁盘配额都合适，再放大规模去跑。