Electron把Node主进程与Chromium渲染进程组合在一起，网络请求可能来自页面、主进程的HTTP客户端、Electron Session或自动更新模块。为某个窗口设置代理后，主进程里的Node请求不一定跟随；反过来，设置Node环境变量也不保证Chromium页面使用。
一、先确认请求由谁发出
| 请求来源 | 常见网络栈 | 代理入口 |
|---|---|---|
| WebContents页面 | Chromium网络栈 | 对应Electron Session |
| 主进程Node请求 | Node/Undici或库 | 库配置、Dispatcher或环境变量 |
| 自动更新 | 更新模块与平台实现 | 需按模块和系统单独验证 |
| 扩展或子进程 | 各自运行时 | 不一定继承应用Session |
二、session.setProxy控制什么
Electron的session.setProxy用于配置特定Session的代理规则。应用可能使用默认Session，也可能用partition创建持久或临时Session。设置时应确认窗口实际绑定的Session，并等待异步配置完成后再发起验证请求。
三、系统代理、参数和Session怎样选择
Electron可受Chromium命令行参数、系统代理和Session配置影响，具体优先级应按当前版本验证。生产应用应选择一个主要配置入口，记录配置版本和回滚方式。多个来源叠加会让用户界面显示一种设置，实际网络却走另一条路径。
四、PAC代理有哪些额外风险
PAC通过脚本按URL或主机选择代理，涉及PAC文件下载、DNS函数、缓存和失败回退。PAC地址不可达时，应用可能直连或失败，取决于策略。企业应用应测试PAC更新、失效和返回DIRECT的边界，并避免在PAC中包含敏感数据。
五、代理切换后为什么仍走旧出口
Chromium会复用HTTP/1.1、HTTP/2和WebSocket连接。新代理规则应用后，已存在连接可能继续传输。应按Electron当前API清理或关闭相关连接，必要时重建Session或窗口，并用新请求核对出口。
连接复用机制见换代理后仍走旧IP的原因。
六、代理认证如何处理
代理返回407时，Electron可能触发登录相关事件或由系统机制处理，具体行为取决于版本和认证方式。凭据不能硬编码在应用包、命令行或日志中。Basic、NTLM等机制兼容性应在目标Windows、macOS和Linux版本上实测。
七、Node主进程为什么要独立配置
主进程若使用Node内置fetch、Undici或第三方库，通常不会自动读取Electron Session代理。应为该HTTP客户端配置明确Dispatcher或代理Agent，并管理独立连接池。可参考Node.js fetch与Undici代理。
八、证书错误在哪一层出现
Chromium页面和Node客户端可能使用不同证书处理路径。企业TLS检查需要操作系统或应用运行时正确信任组织CA。不要在证书错误事件中无条件放行所有证书，这会影响整个应用安全边界。应核对域名、证书链、时间和请求来源。
通用流程见HTTPS代理证书排查。
九、自动更新为什么必须单独测试
更新检查、差分包和完整安装包可能来自不同域名，且更新模块未必使用页面Session。应在签名验证保持开启的情况下，分别测试检查、下载、校验和安装。不要把更新包放到未经验证的镜像，也不要为了代理兼容关闭代码签名。
十、多租户Session如何隔离
不同用户或工作区需要独立Cookie和网络策略时，可使用不同partition，但代理、缓存、证书例外和凭据也要避免串用。配置切换应绑定明确Session，不修改全局状态影响并发窗口。
十一、排查清单
- 记录Electron、Chromium和Node版本；
- 确认请求来自页面、主进程还是更新模块；
- 识别实际Session和partition；
- 只保留一个明确代理来源做验证；
- 区分407、TLS、目标401和连接复用；
- 重建连接或Session后核对出口；
- 检查日志与应用包没有明文秘密。
十二、结论
Electron代理配置必须按网络栈拆分。Session控制Chromium页面，Node客户端和自动更新可能另有路径；只有同时管理连接生命周期、认证和证书，代理切换才真正可控。
