资讯动态

Electron 如何在主进程使用 net.WebSocket 并复用 session 的代理、证书与 Cookie 配置?

发布时间:2026/9/11 6:42:07 来源:尧图企业网站定制
Electron 如何在主进程使用 net.WebSocket 并复用 session 的代理、证书与 Cookie 配置【免费下载链接】electron:electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS项目地址: https://gitcode.com/GitHub_Trending/el/electron在主进程里建立 WebSocket 连接时如果你用 Node.js 的ws库它走的是 Node 自己的网络栈不会读取 Electron 的 session 代理、证书策略或 Cookie。Electron 提供的net.WebSocket是 WHATWGWebSocket接口的主进程替代实现连接走 Chromium 原生网络栈因此可以自动复用 session 级别的配置系统或 session 的代理配置PAC、WPAD、平台信任库加 session 的证书校验策略、session 的自定义 CA 与 host 解析规则以及在开启useSessionCookies后session 的 Cookie。本文按“建立连接 → 绑定 session → 复用代理/证书/Cookie → 验证”的顺序给出可执行的主进程代码路径。前提条件两条硬性限制来自 net 文档与 web-socket 文档netAPI 只能在应用发出ready事件后使用提前使用会抛错net.WebSocket属性仅在主进程可用net.md 明确标注This property is only available in the main process。所有下面的代码都放在app.whenReady()之后执行。建立第一条主进程 WebSocket 连接new net.WebSocket(url[, protocols])的url必须是ws:或wss:协议http:/https:会被自动重写为对应 WebSocket 协议和浏览器行为一致。第二个参数可以是子协议字符串/数组也可以传一个 Electron 扩展的 options 对象——绑定 session、控制 Cookie 都靠它见 WebSocketOptions。最小可用示例来自 web-socket.md 文档示例const { app, net } require(electron) app.whenReady().then(() { const ws new net.WebSocket(wss://echo.websocket.events) ws.onopen () ws.send(hello) ws.onmessage (event) { console.log(received, event.data) ws.close() } })net.WebSocket是EventTarget而不是EventEmitter监听要用addEventListener()或on*事件属性onopen/onmessage/onerror/onclose。连接状态用ws.readyState判断常量为WebSocket.CONNECTING0、OPEN1、CLOSING2、CLOSED3。几个容易踩的行为均来自 web-socket.mdsend(data)在readyState仍为CONNECTING时会抛InvalidStateErrorDOMException所以发数据要放在open事件里close([code][, reason])的code必须是1000或3000–4999之间reason编码后不超过 123 个 UTF-8 字节binaryType默认是 Electron 扩展值nodebuffer二进制消息以Buffer交付设成arraybuffer或blob则与渲染进程WebSocket行为一致。把连接绑定到指定 session代理、证书、Cookie 都是挂在Session上的所以要复用哪套配置取决于这条 WebSocket 属于哪个 session。在构造函数的 options 对象里指定const { app, net, session } require(electron) app.whenReady().then(() { // persist: 前缀 持久 session无此前缀 内存 session const ses session.fromPartition(persist:ws-client) const ws new net.WebSocket(wss://example.com/socket, { session: ses, protocols: [chat] }) ws.onopen () console.log(open) })options 中与本文场景相关的字段WebSocketOptions字段作用默认值session连接关联的Session实例未指定时落到默认 sessionpartition连接关联的 partition 名效果同上但按名字取空字符串即默认 session传了session时此字段被忽略useSessionCookies是否随握手发送 session Cookie 并存握手响应里的 Cookiefalseorigin握手Origin头WebSocket URL 的http(s)等价 origin如连wss://api.example.com发送Origin: https://api.example.com使连接被服务器与 SameSite Cookie 规则视为同源headers随握手附加的 HTTP 头无protocols子协议列表无session 本身的创建规则见 session.mdpartition以persist:开头是持久 session不带前缀是内存 session空字符串返回session.defaultSession。如果你的应用已有窗口加载了某个域名的页面也可以直接取win.webContents.session作为session参数让 WebSocket 与页面共用同一套代理、证书和 Cookie。复用 session 的代理配置代理在 session 上用ses.setProxy(config)设置session.mdconfig的完整结构见 ProxyConfig。mode可选direct、auto_detect从http://wpad/wpad.dat取 PAC 脚本即 WPAD、pac_script从pacScript给的 URL 取脚本、fixed_servers用proxyRules静态规则或system跟随操作系统代理。// 静态代理所有 URL 走 HTTP 代理 127.0.0.1:7890 await ses.setProxy({ mode: fixed_servers, proxyRules: 127.0.0.1:7890 })proxyRules支持按协议分流例如httpfoopy:80;socksfoopy2、带 fallback 的foopy:80,bar,direct://proxyBypassRules指定绕过代理的 URL 规则。两个执行细节setProxy的 Promise 在代理设置流程完成时 resolve。文档提示可能需要再调一次ses.closeAllConnections()否则会复用仍在池化中、走旧代理的 socket。注意closeAllConnections会终止/失败所有 in-flight 请求仅在切换代理这类场景按需调用若走pac_script模式且需要重新拉取 PAC 脚本调用ses.forceReloadProxyConfig()它会把代理服务内部状态重置并按现有配置重新应用。设置后验证是否生效用同 session 的ses.resolveProxy(url)它返回Promisestring即该 URL 实际命中的代理信息const proxyInfo await ses.resolveProxy(wss://example.com) console.log(proxyInfo) // 应输出 127.0.0.1:7890复用 session 的证书策略TLS 证书默认按平台信任库加 session 的证书校验策略验证。要按 session 自定义行为用ses.setCertificateVerifyProc(proc)session.md。proc(request, callback)会在每次服务器证书校验时调用request里带hostname、certificate、validatedCertificate、isIssuedByKnownRoot、verificationResultOK表示受信任否则是CERT_REVOKED之类的错误和errorCode。callback传入0接受该证书同时禁用 Certificate Transparency 校验-2拒绝-3采用 Chromium 自己的验证结果。传null恢复默认校验。文档示例ses.setCertificateVerifyProc((request, callback) { const { hostname } request if (hostname github.com) { callback(0) } else { callback(-2) } })文档同时注明该处理函数的结果会被网络服务缓存。如果你修改了策略但连接行为没变这是文档给出的第一个怀疑点恢复默认用ses.setCertificateVerifyProc(null)。让握手携带 session Cookie默认情况下net.WebSocket不发送也不存储 Cookie。需要把 session 的 Cookie 带进握手时把useSessionCookies设为trueconst { app, net, session } require(electron) app.whenReady().then(async () { const ses session.fromPartition(persist:ws-client) // 向该 session 写入目标域的 Cookie注意 url 要用 ws:// 的 http:// 等价形式 await ses.cookies.set({ url: http://127.0.0.1:8080/, name: ws, value: cookie }) const ws new net.WebSocket(ws://127.0.0.1:8080, { session: ses, useSessionCookies: true }) ws.onopen () console.log(open with cookies) ws.onclose (event) console.log(event.code, event.reason) })两点说明useSessionCookies: true的含义是「随 opening handshake 发送 session Cookie并存握手响应中收到的 Cookie」WebSocketOptions双向都走 session 的 Cookie 存储origin选项默认取 WebSocket URL 的http(s)等价 origin目的是让 SameSite Cookie 规则把这条连接当同源处理。如果你的服务端按不同 Origin 判定或你需要显式覆盖才需要传origin。验证连接与配置是否按预期工作文档给出了三类可直接观察的信号生命周期。open事件发出后握手完成此时readyState为OPENws.protocol与ws.extensions反映与服务器协商出的子协议和扩展如permessage-deflatemessage事件的event.data文本帧是string二进制帧按binaryType给Buffer/ArrayBuffer/Blobclose事件带code、reason、wasClean。失败诊断。error事件一定后随一个close事件。连接失败时握手被拒、网络不可达等close事件的code是1006且 Electron 会把底层网络错误的简短描述写进reason文档明确说这是为了「不挂调试器也能定位失败原因」ws.addEventListener(close, (event) { if (event.code 1006) { console.log(connection failed:, event.reason) } })Cookie 与代理的核对。代理用上一节的ses.resolveProxy(url)核对。Cookie 方面仓库的测试 spec/api-net-websocket-spec.ts 用的验证方式值得直接借鉴起一个本地 WebSocket 服务器捕获握手请求头用{ session: ses, useSessionCookies: true }连接后断言请求头的cookie中包含wscookie同时该 spec 还验证了连接失败时事件顺序是[error, close]且reason匹配net::ERR_\w形式的错误名。本地回显服务器这类最小验证设施不在官方文档正文范围内上述断言值来自仓库 spec按你的实际服务器 URL 与 Cookie 名替换后使用。限制与边界net.WebSocket只在主进程存在渲染进程仍用全局WebSocket不传session/partition时连接落在默认 session此时「复用 session 配置」就是复用session.defaultSession的代理、证书与 CookieuseSessionCookies默认false不开启时握手不带 Cookie——连接成功但服务端读不到登录态时先检查这个字段setProxy后旧的池化连接可能仍在按文档提示配合ses.closeAllConnections()使用证书校验结果被网络服务缓存策略修改不立即生效时先考虑这一点。进一步阅读docs/api/web-socket.md、docs/api/net.md、docs/api/session.md、docs/api/structures/proxy-config.md。【免费下载链接】electron:electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS项目地址: https://gitcode.com/GitHub_Trending/el/electron创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价