[{"data":1,"prerenderedAt":83},["ShallowReactive",2],{"case-https-ssl-skip-decrypt-zh":3,"blog-list-zh":13},{"slug":4,"title":5,"summary":6,"date":7,"featured":8,"seoDescription":9,"series":10,"seriesOrder":11,"html":12},"https-ssl-skip-decrypt","开了 SSL 抓包，有些网站反而打不开？把域名加进「跳过 SSL 代理」","系统代理和证书都没问题，一开 SSL 代理个别站却打不开。多半是源站证书和 Host 对不上。把域名加进「跳过 SSL 代理（隧道）」即可，不必关掉整站 SSL 抓包。","2026-09-01",false,"DevPeek 开了 SSL 代理后部分网站打不开？ERR_TLS_CERT_ALTNAME_INVALID 是源站证书与 Host 不匹配，不是 CA 未信任。用 Include / Exclude：把域名加入「跳过 SSL 代理（隧道）」。","api-debug-new-tricks",3,"\u003Cp>已经设好了系统代理，证书也信任了，SSL 代理同样开着。\u003C/p>\n\u003Cp>大部分 HTTPS 请求都能正常出现在抓包列表里，甚至可以直接看到请求头、请求体和响应内容。\u003C/p>\n\u003Cp>但偏偏有几个网站打不开了。\u003C/p>\n\u003Cp>日志里可能出现这样的错误：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">PROXY_TO_SERVER_REQUEST_ERROR: Error [ERR_TLS_CERT_ALTNAME_INVALID]:\nHostname/IP does not match certificate's altnames:\nHost: admin.shop-example.com. is not in the cert's altnames:\nDNS:*.cdn-host.cn, DNS:cdn-host.cn\n\u003C/code>\u003C/pre>\n\u003Cp>浏览器表现为页面加载失败，抓包列表里的请求也中断。\u003C/p>\n\u003Cp>但把系统代理关掉，或者关闭 SSL 代理之后，网站又恢复正常。\u003C/p>\n\u003Cp>这时候，问题通常不是 DevPeek 根证书没有安装。\u003C/p>\n\u003Cp>真正发生的是：\u003Cstrong>DevPeek 连接源站时，源站返回的证书与当前 Host 不匹配。\u003C/strong>\u003C/p>\n\u003Cp>这种情况下，最简单的办法不是关闭整个 SSL 抓包，而是在 SSL 代理配置里排除这个域名，让它走 HTTPS 隧道。\u003C/p>\n\u003Cp>本文就来看看这条错误到底意味着什么，以及为什么 Include / Exclude 两份名单需要同时存在。\u003C/p>\n\u003Ch2>适合什么情况？\u003C/h2>\n\u003Cp>如果你遇到的是下面这种情况，这篇文章正适合你：\u003C/p>\n\u003Cul>\n\u003Cli>已经配置好系统代理和 DevPeek CA\u003C/li>\n\u003Cli>大部分 HTTPS 都可以正常抓包\u003C/li>\n\u003Cli>只有少数网站开启 SSL 代理后无法访问\u003C/li>\n\u003Cli>日志中出现 \u003Ccode>ERR_TLS_CERT_ALTNAME_INVALID\u003C/code>\u003C/li>\n\u003Cli>报错里的 Host 和证书 SAN 看起来完全不是一个域名\u003C/li>\n\u003Cli>希望只放过这些特殊域名，而不是关闭整个 SSL 抓包\u003C/li>\n\u003C/ul>\n\u003Cp>如果你还没有成功抓到第一个 HTTPS 请求，可以先看：\u003C/p>\n\u003Cul>\n\u003Cli>\u003Ca href=\"/docs/quick-start/\">快速上手\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/docs/install/\">安装与首选项\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/docs/proxy-ssl/\">代理与 SSL 证书\u003C/a>\u003C/li>\n\u003C/ul>\n\u003Ch2>先看懂这条错误\u003C/h2>\n\u003Cp>例如：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">Host: admin.shop-example.com.\nis not in the cert's altnames:\nDNS:*.cdn-host.cn\nDNS:cdn-host.cn\n\u003C/code>\u003C/pre>\n\u003Cp>这里最值得注意的是两部分。\u003C/p>\n\u003Cp>你想访问的 Host：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">admin.shop-example.com\n\u003C/code>\u003C/pre>\n\u003Cp>源站实际返回的证书：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">*.cdn-host.cn\ncdn-host.cn\n\u003C/code>\u003C/pre>\n\u003Cp>证书的 SAN（Subject Alternative Name）里没有 \u003Ccode>admin.shop-example.com\u003C/code>。\u003C/p>\n\u003Cp>因此，Node 在连接源站时进行 TLS 证书主机名校验，发现：我正在连接 \u003Ccode>admin.shop-example.com\u003C/code>，但你给我的证书是 \u003Ccode>*.cdn-host.cn\u003C/code>。\u003C/p>\n\u003Cp>于是连接失败。这就是 \u003Ccode>ERR_TLS_CERT_ALTNAME_INVALID\u003C/code>。\u003C/p>\n\u003Ch2>这不是「没装 DevPeek 证书」\u003C/h2>\n\u003Cp>这是最容易搞混的地方。\u003C/p>\n\u003Cp>如果 DevPeek CA 没有被浏览器或设备信任，通常看到的是类似：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">NET::ERR_CERT_AUTHORITY_INVALID\n\u003C/code>\u003C/pre>\n\u003Cp>也就是：这个证书的颁发者，我不信任。\u003C/p>\n\u003Cp>而本文讨论的是另一种情况：\u003Ccode>ERR_TLS_CERT_ALTNAME_INVALID\u003C/code>。\u003C/p>\n\u003Cp>它关注的是：证书里的域名，与当前连接的 Host 对不上。\u003C/p>\n\u003Cp>所以，如果你看到 Host 是 \u003Ccode>admin.shop-example.com\u003C/code>，证书却是 \u003Ccode>DNS:*.cdn-host.cn\u003C/code>，继续重装 DevPeek CA 通常没有意义。\u003C/p>\n\u003Ch2>为什么只开 SSL 代理时会出问题？\u003C/h2>\n\u003Cp>理解这个问题，关键是知道 SSL 代理实际上发生了什么。\u003C/p>\n\u003Cp>普通 HTTPS 代理连接大致是：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">浏览器\n   │\n   │ CONNECT\n   ▼\nDevPeek\n   │\n   │ TCP 隧道\n   ▼\n源站\n\u003C/code>\u003C/pre>\n\u003Cp>TLS 握手仍然由浏览器直接与源站完成。DevPeek 只是把连接「穿过去」。所以浏览器 ↔ 源站之间的 TLS 证书由浏览器自己验证。\u003C/p>\n\u003Cp>而开启 SSL 代理之后，情况变成了两段 TLS：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">浏览器\n   │\n   │ TLS\n   ▼\nDevPeek\n   │\n   │ TLS\n   ▼\n源站\n\u003C/code>\u003C/pre>\n\u003Cp>第一段：浏览器 ↔ DevPeek。DevPeek 会动态生成对应域名的证书，并使用 DevPeek CA 签发。\u003C/p>\n\u003Cp>第二段：DevPeek ↔ 源站。DevPeek 作为 TLS 客户端连接真实网站，并验证源站返回的证书。\u003C/p>\n\u003Cp>因此，本文的错误发生在第二段。\u003C/p>\n\u003Ch2>为什么 CDN、WAF 特别容易碰到这种情况？\u003C/h2>\n\u003Cp>实际网络环境里，一个 IP 往往并不只服务一个网站。\u003C/p>\n\u003Cp>例如 \u003Ccode>admin.shop-example.com\u003C/code>、\u003Ccode>api.shop-example.com\u003C/code>、\u003Ccode>cdn-host.cn\u003C/code>、\u003Ccode>static.cdn-host.cn\u003C/code> 可能最终都经过同一个 CDN、WAF 或反向代理。\u003C/p>\n\u003Cp>正常情况下，服务器会根据 TLS 握手中的 SNI 选择正确的证书。\u003C/p>\n\u003Cp>但如果代理链、客户端、CDN 配置或者 Host / SNI 处理存在异常，就可能出现：请求的 Host 是 \u003Ccode>admin.shop-example.com\u003C/code>，源站返回 \u003Ccode>*.cdn-host.cn\u003C/code>。\u003C/p>\n\u003Cp>这时候浏览器直连可能正常，但经过 SSL 中间人代理之后出现证书主机名错误。\u003C/p>\n\u003Cp>另外，如果你看到 Host 写成 \u003Ccode>admin.shop-example.com.\u003C/code>，末尾多了一个 \u003Ccode>.\u003C/code>，也值得留意。这是 FQDN 的合法写法，本身并不代表错误，但某些客户端、代理或 CDN 在处理这种形式时可能存在兼容性问题。\u003C/p>\n\u003Ch2>为什么不能「失败之后自动变成隧道」？\u003C/h2>\n\u003Cp>你可能会想到一个很自然的方案：DevPeek 第一次尝试 SSL 代理失败了，那就自动改成普通 CONNECT 隧道不就行了？\u003C/p>\n\u003Cp>问题在于，到了这里已经晚了。\u003C/p>\n\u003Cp>SSL 代理建立的是浏览器 ↔ DevPeek 的 TLS 连接。浏览器的 ClientHello 已经交给 DevPeek 处理，DevPeek 也已经开始作为中间人连接源站。\u003C/p>\n\u003Cp>如果这时候源站证书校验失败，原来的 CONNECT 已经不能简单地「倒退」回透明隧道。因此，隧道通常需要在建立连接之前就决定。\u003C/p>\n\u003Cp>这也是为什么 Fiddler、Charles 等代理工具同样提供「哪些 Host 做 SSL 代理、哪些 Host 跳过」的配置，而不是等证书校验失败之后再自动降级。Charles 把这两份名单叫 \u003Cstrong>Include / Exclude\u003C/strong>。\u003C/p>\n\u003Ch2>DevPeek 怎么处理？\u003C/h2>\n\u003Cp>DevPeek 把 SSL 代理范围拆成两份名单：\u003C/p>\n\u003Cp>\u003Cstrong>SSL 代理这些主机\u003C/strong>，也就是 Include。默认 \u003Ccode>*\u003C/code>，代表所有符合条件的 HTTPS Host 都允许进行 SSL 代理。\u003C/p>\n\u003Cp>\u003Cstrong>跳过 SSL 代理（隧道）\u003C/strong>，也就是 Exclude。这里列出的 Host 不做 SSL 中间人代理，而是直接建立 HTTPS 隧道。\u003C/p>\n\u003Cp>最终规则可以简单理解为：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">做 SSL 代理\n= SSL 已开启\n  && 命中 Include\n  && 未命中 Exclude\n\u003C/code>\u003C/pre>\n\u003Cp>Include 和 Exclude 同时命中时，Exclude 优先。\u003C/p>\n\u003Cp>这与参数转换里的加解密规则无关。\u003C/p>\n\u003Ch2>在 SSL 代理配置里排除这个域名\u003C/h2>\n\u003Cp>打开 DevPeek 的 \u003Cstrong>SSL 代理配置\u003C/strong>。\u003C/p>\n\u003Cp>上面是 \u003Cstrong>SSL 代理这些主机\u003C/strong>，下面是 \u003Cstrong>跳过 SSL 代理（隧道）\u003C/strong>。\u003C/p>\n\u003Cp>例如现在 Include 是 \u003Ccode>*\u003C/code>，而 \u003Ccode>admin.shop-example.com\u003C/code> 开启 SSL 代理时出现 \u003Ccode>ERR_TLS_CERT_ALTNAME_INVALID\u003C/code>，那么可以在 Exclude 中加入：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">admin.shop-example.com\n\u003C/code>\u003C/pre>\n\u003Cp>如果这个站点的一整个子域都存在类似问题，也可以使用：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">*.shop-example.com\n\u003C/code>\u003C/pre>\n\u003Cp>保存之后，后续建立的连接会按照新规则处理。已经建立的 CONNECT 不会自动变成隧道，因此修改配置后刷新页面，必要时清掉旧连接再测试。\u003C/p>\n\u003Cp>\u003Cstrong>完成标准：\u003C/strong> 该站能打开，抓包列表里对应 HTTPS 是隧道；其它仍在 Include 内的域名继续做 SSL 代理。\u003C/p>\n\u003Ch2>Include / Exclude 怎么配？\u003C/h2>\n\u003Cp>规则支持通配符，例如 \u003Ccode>*\u003C/code>、\u003Ccode>*.example.com\u003C/code>、\u003Ccode>*api*\u003C/code>、\u003Ccode>api.example.com\u003C/code>。\u003C/p>\n\u003Cp>几个典型情况：\u003C/p>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Include\u003C/th>\n\u003Cth>Exclude\u003C/th>\n\u003Cth>访问 Host\u003C/th>\n\u003Cth>结果\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>\u003Ccode>*\u003C/code>\u003C/td>\n\u003Ctd>\u003Ccode>*.shop-example.com\u003C/code>\u003C/td>\n\u003Ctd>\u003Ccode>admin.shop-example.com\u003C/code>\u003C/td>\n\u003Ctd>隧道\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>*\u003C/code>\u003C/td>\n\u003Ctd>\u003Ccode>*.shop-example.com\u003C/code>\u003C/td>\n\u003Ctd>\u003Ccode>api.other.com\u003C/code>\u003C/td>\n\u003Ctd>SSL 代理\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>*.example.com\u003C/code>\u003C/td>\n\u003Ctd>\u003Ccode>api.example.com\u003C/code>\u003C/td>\n\u003Ctd>\u003Ccode>api.example.com\u003C/code>\u003C/td>\n\u003Ctd>隧道\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>api.example.com\u003C/code>\u003C/td>\n\u003Ctd>\u003Ccode>*.example.com\u003C/code>\u003C/td>\n\u003Ctd>\u003Ccode>api.example.com\u003C/code>\u003C/td>\n\u003Ctd>隧道\u003C/td>\n\u003C/tr>\n\u003C/tbody>\u003C/table>\n\u003Cp>核心原则只有一个：\u003Cstrong>排除优先。\u003C/strong> 因此即使一个 Host 同时命中 Include 和 Exclude，也会走隧道。\u003C/p>\n\u003Cp>排除名单里加入 \u003Ccode>*\u003C/code>，则相当于把所有 HTTPS 都排除掉，也就是全部走隧道。DevPeek 会在保存前进行确认，避免误操作导致整个 SSL 抓包突然「消失」。\u003C/p>\n\u003Ch2>一个容易忽略的点：不能按 URL Path 排除\u003C/h2>\n\u003Cp>例如你可能想写 \u003Ccode>https://api.example.com/login\u003C/code>，或者 \u003Ccode>api.example.com/v1/*\u003C/code>。\u003C/p>\n\u003Cp>但 SSL 代理的决定发生在 HTTPS CONNECT 阶段。此时代理还没有看到 \u003Ccode>/v1/login\u003C/code> 这样的 HTTP URL Path。\u003C/p>\n\u003Cp>因此 SSL 代理排除只能根据 Host 等连接级信息进行匹配。也就是说：\u003Ccode>api.example.com\u003C/code> 可以，但 \u003Ccode>api.example.com/v1/login\u003C/code> 不是一条 SSL 代理 Host 规则。\u003C/p>\n\u003Ch2>不要把三个问题混在一起\u003C/h2>\n\u003Cp>遇到 HTTPS 抓包异常时，可以先用下面这张表快速判断：\u003C/p>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>现象\u003C/th>\n\u003Cth>更可能是什么问题\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>浏览器提示「不受信任的颁发者」/ \u003Ccode>NET::ERR_CERT_AUTHORITY_INVALID\u003C/code>\u003C/td>\n\u003Ctd>DevPeek CA 没有正确安装或信任\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Host 是 A，源站证书 SAN 却是完全不同的域名；直连正常，SSL 代理才失败\u003C/td>\n\u003Ctd>源站证书 / SNI / 代理链兼容问题\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>关闭 SSL 代理后该站仍然提示证书错误\u003C/td>\n\u003Ctd>源站自己的证书就存在问题\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>HTTPS 已经成功拆开，但 JSON 中仍然是密文\u003C/td>\n\u003Ctd>\u003Ca href=\"/docs/param-transform/\">参数转换 / 加解密规则\u003C/a>\u003C/td>\n\u003C/tr>\n\u003C/tbody>\u003C/table>\n\u003Cp>尤其注意最后一种：HTTPS 已经是明文 HTTP 了，JSON 里面还是 \u003Ccode>{ "data": "7a3f..." }\u003C/code>。这不是 SSL 代理的问题，这是应用层的参数加密，可以交给 \u003Ca href=\"/docs/param-transform/\">参数转换\u003C/a> 处理。\u003C/p>\n\u003Ch2>那么，什么时候应该跳过 SSL 代理？\u003C/h2>\n\u003Cp>通常有三类情况。\u003C/p>\n\u003Ch3>1. 源站证书与 Host 存在兼容问题\u003C/h3>\n\u003Cp>例如本文的 \u003Ccode>ERR_TLS_CERT_ALTNAME_INVALID\u003C/code>。直接把问题域加入 Exclude，让它恢复成普通 HTTPS 隧道。\u003C/p>\n\u003Ch3>2. 这个站点本来就不需要抓明文\u003C/h3>\n\u003Cp>例如 \u003Ccode>*.google-analytics.com\u003C/code>、\u003Ccode>*.example-cdn.com\u003C/code>。这些流量只是背景请求，你并不关心它的 HTTPS 内容。把它们排除，可以减少抓包噪声。\u003C/p>\n\u003Ch3>3. 某些客户端使用了证书固定等机制\u003C/h3>\n\u003Cp>如果某个应用不适合被中间人代理，或者你根本不需要查看它的 HTTPS 明文，也可以让对应 Host 直接走隧道。\u003C/p>\n\u003Cp>这里要注意：跳过 SSL 代理并不是「解决证书固定」，而是选择不对这部分流量进行 SSL 中间人代理。\u003C/p>\n\u003Ch2>不要为了几个网站关闭整个 SSL 代理\u003C/h2>\n\u003Cp>这是最重要的使用建议。\u003C/p>\n\u003Cp>如果只有 \u003Ccode>admin.shop-example.com\u003C/code> 有问题，没有必要把整个 SSL 代理关掉。也没有必要为了绕过一个站点的源站证书问题，就关闭全局的源站证书校验。后者相当于让代理不再认真验证自己连接的真实源站。\u003C/p>\n\u003Cp>正确的思路应该是：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">大部分域名\n    ↓\nSSL 代理\n    ↓\n需要明文抓包\n\n少数特殊域名\n    ↓\n跳过 SSL 代理\n    ↓\nHTTPS 隧道\n\u003C/code>\u003C/pre>\n\u003Cp>两种模式可以在同一套代理配置里长期共存。\u003C/p>\n\u003Ch2>最终可以记住这一句话\u003C/h2>\n\u003Cp>如果：直连正常 + 开启 SSL 代理后某个站点失败 + Host 与源站证书 SAN 不匹配，那么优先检查 \u003Cstrong>「跳过 SSL 代理（隧道）」\u003C/strong>，而不是重新安装 CA，也不是关闭整个 SSL 抓包。\u003C/p>\n\u003Cp>最终的判断逻辑就是：\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">Include\n   │\n   ├── 未命中 → 不做 SSL 代理\n   │\n   └── 命中\n        │\n        ├── Exclude 命中 → 隧道\n        │\n        └── Exclude 未命中 → SSL 代理\n\u003C/code>\u003C/pre>\n\u003Cp>这样既可以保持大部分 HTTPS 的明文抓包，也不会因为少数特殊站点把整个代理配置关掉。\u003C/p>\n\u003Ch2>下一步\u003C/h2>\n\u003Cp>如果你需要继续处理接口调试，可以沿着同一条代理链继续往下：\u003C/p>\n\u003Cul>\n\u003Cli>\u003Ca href=\"/docs/param-transform/\">参数转换\u003C/a>：处理 AES、Base64 等参数编解码\u003C/li>\n\u003Cli>\u003Ca href=\"/docs/map-route/\">转发规则\u003C/a>：接口已经迁移，前端还没发版？直接改到新服务\u003C/li>\n\u003Cli>\u003Ca href=\"/docs/mock/\">Mock\u003C/a>：不改后端，直接模拟接口响应\u003C/li>\n\u003Cli>\u003Ca href=\"/docs/capture/\">抓包界面与请求详情\u003C/a>：查看和分析 HTTP / HTTPS / WebSocket 流量\u003C/li>\n\u003C/ul>\n\u003Cp>如果只是想解决本文这个问题，通常只需要：找到出问题的 Host → 在 SSL 代理配置里排除它 → 刷新连接。\u003C/p>\n\u003Ch2>下一篇\u003C/h2>\n\u003Cp>\u003Cstrong>《待整理：代理链上的断点、重发与协作》\u003C/strong>——继续聊接口联调中那些容易被代理工具「卡住」的细节。\u003C/p>\n\u003Chr>\n\u003Cp>如果你也遇到过「一开 SSL 代理，个别网站反而打不开」，欢迎 \u003Ca href=\"/\">下载 DevPeek\u003C/a> 试试在 SSL 代理配置中增加一条排除规则，也可以到 \u003Ca href=\"https://github.com/GYPengDev/devpeek/discussions\">GitHub Discussions\u003C/a> 交流你遇到的证书、CDN 或代理兼容问题。\u003C/p>\n\u003Ch2>相关文档\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"/docs/proxy-ssl/\">代理与 SSL 证书\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/docs/faq/\">常见问题\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/docs/capture/\">抓包界面与请求详情\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/docs/quick-start/\">快速上手\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/blog/install-first-capture/\">零基础上手：安装 DevPeek 并抓到第一个包\u003C/a>\u003C/li>\n\u003C/ul>\n\u003Ch2>系列文章\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"/blog/api-param-encryption-debug/\">H5 接口参数加密？DevPeek 一键解密调试\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/blog/mock-map-route-split-api/\">API 已迁新服务，前端还没发版？用「转发规则」联调\u003C/a>\u003C/li>\n\u003C/ul>\n",{"items":14},[15,16,24,30,37,44,50,56,64,70,77],{"slug":4,"title":5,"summary":6,"date":7,"featured":8,"seoDescription":9,"series":10,"seriesOrder":11},{"slug":17,"title":18,"summary":19,"date":20,"featured":8,"seoDescription":21,"series":22,"seriesOrder":23},"dev-build-log-silent-auto-update","换掉 Electron 后，自动更新也得重做","DevPeek 换成 Tauri 后，更新的不只是一个窗口，而是 Launcher、Core 和 Shell 三个进程。我们把检查和下载挪到后台，等安装包准备好后，再由托盘完成最后一次重启。","2026-08-28","DevPeek 开发实录：桌面端从 Electron 换到 Tauri 后，如何为 Launcher、Core 和 Shell 重做自动更新，并避免更新过程影响系统代理。","dev-build-log",4,{"slug":25,"title":26,"summary":27,"date":28,"featured":8,"seoDescription":29,"series":22,"seriesOrder":11},"dev-build-log-ws-mock-dsl","为什么我们重新设计了 WebSocket Mock DSL，而不是用 YAML、JSON 或 JS","轻量 WebSocket Mock 不该比 HTTP Mock 更重。YAML、JSON、JS 都能做，但写「连上、登录、心跳」太啰嗦。我们自研短 DSL，就是让轻量 Mock 更轻。","2026-08-13","DevPeek 开发实录：为什么 WebSocket Mock 自研 Flow DSL。现成 YAML、JSON、JS 能做重活；轻量顺序剧本用更短的文本来写。",{"slug":31,"title":32,"summary":33,"date":34,"featured":8,"seoDescription":35,"series":22,"seriesOrder":36},"dev-build-log-electron-to-tauri","DevPeek 架构改造：抛弃 Electron，拥抱 Tauri","联调工具不该为「开一个窗口」再拖一整套 Chromium。我们把业务收到 Core，桌面壳换成 Tauri，安装更轻、后台更省，关窗后托盘里也能随时唤回来。","2026-08-08","DevPeek 开发实录：桌面壳从 Electron 迁到 Tauri，业务留在 Core，壳只负责窗口与系统能力，体积与资源占用更友好。",2,{"slug":38,"title":39,"summary":40,"date":41,"featured":8,"seoDescription":42,"series":22,"seriesOrder":43},"dev-build-log-sqljs-to-better-sqlite3","抓包历史为什么从 sql.js 迁到原生 SQLite","早期 DevPeek 用纯 JavaScript 版 SQLite 存抓包记录，联调一忙就占内存、列表发紧。我们换成系统级原生 SQLite 后，代理可以连续挂一整天，内存也稳。","2026-08-05","DevPeek 开发实录：抓包历史存储从 sql.js 换成原生 SQLite，解决长时间联调内存上涨、列表卡顿，让代理可以挂一整天。",1,{"slug":45,"title":46,"summary":47,"date":48,"featured":8,"seoDescription":49,"series":10,"seriesOrder":36},"mock-map-route-split-api","API 已迁新服务，前端还没发版？用「转发规则」联调","服务拆分后，前端仍请求旧 API，订单接口却已经迁到新服务。使用 DevPeek「转发规则」无需修改前端代码，即可把指定接口转发到新域名；若新服务未完成，还可以用 Mock 先跑通页面。","2026-07-26","微服务联调与 API 域名迁移：用 DevPeek「转发规则」做 API 转发，不改前端即可把旧域名请求指到新服务；服务迁移未完成时可用 Mock 先验页面。附接口联调 Demo。",{"slug":51,"title":52,"summary":53,"date":54,"featured":8,"seoDescription":55,"series":10,"seriesOrder":43},"api-param-encryption-debug","H5 接口参数加密？DevPeek 一键解密调试","联调时接口参数 AES 加密看不到明文？用 DevPeek 参数转换功能，填好密钥和 IV 就能自动解密，还能改参重放。","2026-07-18","用 DevPeek 参数转换功能解密 AES-GCM 加密的 H5 API 请求，支持双向转换、明文编辑、调试重放。",{"slug":57,"title":58,"summary":59,"date":60,"featured":61,"seoDescription":62,"series":63,"seriesOrder":36},"h5-debug-console-mock","H5 调试实战（二）：Android WebView 白屏排查，从 Console 远程定位到 Mock 验证","活动 H5 在部分 Android 设备中点击按钮后白屏，请求全部 200 却没有页面反馈。通过 DevPeek Console 获取线上 WebView 运行日志，远程 eval 确认 polyfill 覆盖问题，再使用 Mock 验证异常状态下的降级页面。","2026-07-13",true,"H5 调试实战第二篇：排查 Android WebView 白屏问题。通过 Console 远程调试定位 JavaScript polyfill 兼容问题，并结合 Mock 验证接口异常场景下的页面降级逻辑。","h5-debug",{"slug":65,"title":66,"summary":67,"date":68,"featured":61,"seoDescription":69,"series":63,"seriesOrder":43},"wechat-h5-storage-debug","H5 调试实战（一）：微信 H5 localStorage 调试，在电脑上修改真机缓存","微信 H5 换测试号后头像仍显示旧用户，抓包确认接口正常，却定位到 localStorage 遗留旧数据。本文记录一次真实联调过程，以及如何在电脑上查看、修改微信 WebView 的 localStorage、sessionStorage 和 IndexedDB。","2026-07-11","微信 H5 调试实战：通过真实案例定位 localStorage、sessionStorage、IndexedDB 导致的数据缓存问题，对比 vConsole、Remote Debug 等方案，介绍真机 WebView 调试思路。",{"slug":71,"title":72,"summary":73,"date":74,"featured":61,"seoDescription":75,"series":76,"seriesOrder":36},"why-we-built-devpeek-h5-debug","我们为什么做 DevPeek（二）：App 里那页 H5，在电脑上也能对着查","登录接口用参数转换啃下来了，活动页 H5 却在 App WebView 里才崩。真机 remote debug 折腾一圈，DOM 和抓包还是两拨窗口——于是把镜像和自研调试面板收进 DevPeek。","2026-07-10","DevPeek 起源系列第二篇：App 内嵌 H5 只在真机出问题、remote debug 与抓包割裂的联调痛点，以及调试 Tab 如何把页面镜像到电脑并用自研面板查 DOM、Console 与 Network。","origin",{"slug":78,"title":79,"summary":80,"date":81,"featured":61,"seoDescription":82,"series":76,"seriesOrder":43},"why-we-built-devpeek","我们为什么做 DevPeek（一）：HTTPS 解密了，Body 还是天书","版本日前那晚，TLS 早就解开了，改请求里一个字段却还要翻脚本加解密。于是萌生做一个把业务加解密收进代理的工具——DevPeek 从这儿开始。","2026-07-09","DevPeek 起源系列第一篇：联调时请求体加解密的手工折腾，以及为什么先做一款把业务加解密收进代理的工具。",1788161402876]