[{"data":1,"prerenderedAt":83},["ShallowReactive",2],{"case-https-ssl-skip-decrypt-en":3,"blog-list-en":13},{"slug":4,"title":5,"summary":6,"date":7,"featured":8,"seoDescription":9,"series":10,"seriesOrder":11,"html":12},"https-ssl-skip-decrypt","HTTPS Capture Breaks a Few Sites? Add Them to Skip SSL Proxy","Proxy and CA are fine, but a few sites die as soon as SSL proxying is on. Usually the origin cert does not match Host. Put that domain on Skip SSL proxy (tunnel)—do not turn off HTTPS capture for everything.","2026-09-01",false,"DevPeek SSL proxying makes some sites fail? ERR_TLS_CERT_ALTNAME_INVALID is origin cert vs Host, not an untrusted CA. Use Include / Exclude: add the host to Skip SSL proxy (tunnel).","api-debug-new-tricks",3,"\u003Cp>System proxy is on. The CA is trusted. SSL proxying is on too.\u003C/p>\n\u003Cp>Most HTTPS requests show up in the capture list—headers, bodies, responses, all readable.\u003C/p>\n\u003Cp>A few sites just will not load.\u003C/p>\n\u003Cp>The log may look like this:\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>The browser fails the page. The capture row dies.\u003C/p>\n\u003Cp>Turn off system proxy, or turn off SSL proxying, and the site works again.\u003C/p>\n\u003Cp>Usually this is \u003Cstrong>not\u003C/strong> a missing DevPeek root CA.\u003C/p>\n\u003Cp>What actually happened: \u003Cstrong>when DevPeek connected to the origin, the certificate the server returned did not match the current Host.\u003C/strong>\u003C/p>\n\u003Cp>The simple fix is not to disable HTTPS capture globally. Exclude that host in SSL proxy settings and let it use an HTTPS tunnel.\u003C/p>\n\u003Cp>This post unpacks the error, and why you need both Include and Exclude lists.\u003C/p>\n\u003Ch2>Who this is for\u003C/h2>\n\u003Cp>This article is for you if:\u003C/p>\n\u003Cul>\n\u003Cli>System proxy and the DevPeek CA are already set up\u003C/li>\n\u003Cli>Most HTTPS captures fine\u003C/li>\n\u003Cli>Only a few sites break when SSL proxying is on\u003C/li>\n\u003Cli>The log shows \u003Ccode>ERR_TLS_CERT_ALTNAME_INVALID\u003C/code>\u003C/li>\n\u003Cli>The Host in the error and the cert SAN look like different domains\u003C/li>\n\u003Cli>You want to spare those hosts, not turn off SSL proxying for everything\u003C/li>\n\u003C/ul>\n\u003Cp>If you have not captured a first HTTPS request yet, start here:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Ca href=\"/en/docs/quick-start/\">Quick Start\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/en/docs/install/\">Install & preferences\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/en/docs/proxy-ssl/\">Proxy & SSL certificates\u003C/a>\u003C/li>\n\u003C/ul>\n\u003Ch2>Read the error first\u003C/h2>\n\u003Cp>For example:\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>Two parts matter.\u003C/p>\n\u003Cp>The Host you meant to open:\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">admin.shop-example.com\n\u003C/code>\u003C/pre>\n\u003Cp>The certificate the origin actually presented:\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">*.cdn-host.cn\ncdn-host.cn\n\u003C/code>\u003C/pre>\n\u003Cp>\u003Ccode>admin.shop-example.com\u003C/code> is not in the cert’s SAN (Subject Alternative Name).\u003C/p>\n\u003Cp>So when Node verifies the origin TLS cert, it sees: I am connecting to \u003Ccode>admin.shop-example.com\u003C/code>, but you handed me \u003Ccode>*.cdn-host.cn\u003C/code>.\u003C/p>\n\u003Cp>The connection fails. That is \u003Ccode>ERR_TLS_CERT_ALTNAME_INVALID\u003C/code>.\u003C/p>\n\u003Ch2>This is not “DevPeek CA not installed”\u003C/h2>\n\u003Cp>Easy to mix up.\u003C/p>\n\u003Cp>If the browser or device does not trust the DevPeek CA, you usually get something like:\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">NET::ERR_CERT_AUTHORITY_INVALID\n\u003C/code>\u003C/pre>\n\u003Cp>Meaning: I do not trust who issued this certificate.\u003C/p>\n\u003Cp>This article is the other error: \u003Ccode>ERR_TLS_CERT_ALTNAME_INVALID\u003C/code>.\u003C/p>\n\u003Cp>It asks: do the names on the certificate match the Host we are connecting to?\u003C/p>\n\u003Cp>If Host is \u003Ccode>admin.shop-example.com\u003C/code> and the cert is \u003Ccode>DNS:*.cdn-host.cn\u003C/code>, reinstalling the DevPeek CA will not help.\u003C/p>\n\u003Ch2>Why it only breaks with SSL proxying on\u003C/h2>\n\u003Cp>You have to see what SSL proxying actually does.\u003C/p>\n\u003Cp>A plain HTTPS proxy looks like this:\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">Browser\n   │\n   │ CONNECT\n   ▼\nDevPeek\n   │\n   │ TCP tunnel\n   ▼\nOrigin\n\u003C/code>\u003C/pre>\n\u003Cp>The browser still completes TLS with the origin. DevPeek only splices the TCP. The browser verifies the origin certificate itself.\u003C/p>\n\u003Cp>With SSL proxying on, there are two TLS sessions:\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">Browser\n   │\n   │ TLS\n   ▼\nDevPeek\n   │\n   │ TLS\n   ▼\nOrigin\n\u003C/code>\u003C/pre>\n\u003Cp>First hop: browser ↔ DevPeek. DevPeek mints a cert for that name, signed by the DevPeek CA.\u003C/p>\n\u003Cp>Second hop: DevPeek ↔ origin. DevPeek is the TLS client and verifies the real site certificate.\u003C/p>\n\u003Cp>The error in this article is the second hop.\u003C/p>\n\u003Ch2>Why CDNs and WAFs hit this so often\u003C/h2>\n\u003Cp>One IP often serves many names.\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> may all sit behind the same CDN, WAF, or reverse proxy.\u003C/p>\n\u003Cp>Normally the server picks a cert from the SNI in the TLS handshake.\u003C/p>\n\u003Cp>If the proxy chain, the client, CDN config, or Host / SNI handling is off, you can request Host \u003Ccode>admin.shop-example.com\u003C/code> and get back \u003Ccode>*.cdn-host.cn\u003C/code>.\u003C/p>\n\u003Cp>Browser direct may still work. Through an SSL MITM proxy, hostname verification fails.\u003C/p>\n\u003Cp>If you see Host written \u003Ccode>admin.shop-example.com.\u003C/code> with a trailing dot, note it. That is a valid FQDN. It is not itself a bug, but some clients, proxies, or CDNs handle that form poorly.\u003C/p>\n\u003Ch2>Why not “fail, then automatically tunnel”?\u003C/h2>\n\u003Cp>A natural idea: if the first SSL-proxy attempt fails, fall back to a plain CONNECT tunnel.\u003C/p>\n\u003Cp>Too late.\u003C/p>\n\u003Cp>SSL proxying already built TLS between the browser and DevPeek. The browser’s ClientHello went to DevPeek. DevPeek has already started talking to the origin as a MITM.\u003C/p>\n\u003Cp>If origin cert check fails, that CONNECT cannot simply rewind into a transparent tunnel. Tunnel vs intercept has to be decided \u003Cstrong>before\u003C/strong> the connection is established.\u003C/p>\n\u003Cp>That is why Fiddler, Charles, and similar tools let you configure which hosts get SSL intercept and which are skipped, instead of auto-downgrading after a bad cert. Charles calls the two lists \u003Cstrong>Include / Exclude\u003C/strong>.\u003C/p>\n\u003Ch2>How DevPeek handles it\u003C/h2>\n\u003Cp>DevPeek splits SSL proxy scope into two lists:\u003C/p>\n\u003Cp>\u003Cstrong>SSL proxy these hosts\u003C/strong> — Include. Default \u003Ccode>*\u003C/code> means every matching HTTPS host may be intercepted.\u003C/p>\n\u003Cp>\u003Cstrong>Skip SSL proxy (tunnel)\u003C/strong> — Exclude. Those hosts are not MITM’d; they get an HTTPS tunnel.\u003C/p>\n\u003Cp>In one line:\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">SSL proxy\n= SSL on\n  && Include match\n  && not Exclude match\n\u003C/code>\u003C/pre>\n\u003Cp>If both match, Exclude wins.\u003C/p>\n\u003Cp>This is not param encrypt/decrypt in \u003Ca href=\"/en/docs/param-transform/\">Param Transform\u003C/a>.\u003C/p>\n\u003Ch2>Exclude the host in SSL proxy settings\u003C/h2>\n\u003Cp>Open \u003Cstrong>SSL proxy configuration\u003C/strong>.\u003C/p>\n\u003Cp>Top: \u003Cstrong>SSL proxy these hosts\u003C/strong>. Bottom: \u003Cstrong>Skip SSL proxy (tunnel)\u003C/strong>.\u003C/p>\n\u003Cp>If Include is \u003Ccode>*\u003C/code> and \u003Ccode>admin.shop-example.com\u003C/code> fails with \u003Ccode>ERR_TLS_CERT_ALTNAME_INVALID\u003C/code>, add to Exclude:\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">admin.shop-example.com\n\u003C/code>\u003C/pre>\n\u003Cp>If a whole subtree has the same issue:\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">*.shop-example.com\n\u003C/code>\u003C/pre>\n\u003Cp>Save applies to \u003Cstrong>new\u003C/strong> connections. An existing CONNECT will not flip to a tunnel. Refresh the page; drop old connections if you need to.\u003C/p>\n\u003Cp>\u003Cstrong>Done when:\u003C/strong> the site loads, that HTTPS row is a tunnel, and other Include hosts still get SSL proxying.\u003C/p>\n\u003Ch2>How to write Include / Exclude\u003C/h2>\n\u003Cp>Patterns: \u003Ccode>*\u003C/code>, \u003Ccode>*.example.com\u003C/code>, \u003Ccode>*api*\u003C/code>, \u003Ccode>api.example.com\u003C/code>.\u003C/p>\n\u003Cp>Typical cases:\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>Result\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>Tunnel\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 proxy\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>Tunnel\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>Tunnel\u003C/td>\n\u003C/tr>\n\u003C/tbody>\u003C/table>\n\u003Cp>One rule: \u003Cstrong>Exclude wins.\u003C/strong> A host on both lists still tunnels.\u003C/p>\n\u003Cp>Putting \u003Ccode>*\u003C/code> on Exclude tunnels all HTTPS. DevPeek asks for confirmation so you do not wipe out SSL capture by accident.\u003C/p>\n\u003Ch2>Easy to miss: you cannot exclude by URL path\u003C/h2>\n\u003Cp>You might want \u003Ccode>https://api.example.com/login\u003C/code> or \u003Ccode>api.example.com/v1/*\u003C/code>.\u003C/p>\n\u003Cp>SSL proxy vs tunnel is decided at HTTPS CONNECT. The proxy has not seen \u003Ccode>/v1/login\u003C/code> yet.\u003C/p>\n\u003Cp>Exclude matches connection-level Host, not HTTP path. \u003Ccode>api.example.com\u003C/code> is a rule. \u003Ccode>api.example.com/v1/login\u003C/code> is not.\u003C/p>\n\u003Ch2>Do not mix three different failures\u003C/h2>\n\u003Cp>When HTTPS capture looks wrong, start here:\u003C/p>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>What you see\u003C/th>\n\u003Cth>More likely\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Untrusted issuer / \u003Ccode>NET::ERR_CERT_AUTHORITY_INVALID\u003C/code>\u003C/td>\n\u003Ctd>DevPeek CA not installed or not trusted\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Host is A, origin SAN is a different domain; direct works, SSL proxying fails\u003C/td>\n\u003Ctd>Origin cert / SNI / proxy-chain mismatch\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Cert error remains with SSL proxying off\u003C/td>\n\u003Ctd>The origin cert is already wrong\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>HTTPS is already HTTP plaintext, JSON still ciphertext\u003C/td>\n\u003Ctd>\u003Ca href=\"/en/docs/param-transform/\">Param Transform\u003C/a>\u003C/td>\n\u003C/tr>\n\u003C/tbody>\u003C/table>\n\u003Cp>Watch the last one: TLS is already open, but the JSON is still \u003Ccode>{ "data": "7a3f..." }\u003C/code>. That is application-layer encryption, not SSL proxying. Use \u003Ca href=\"/en/docs/param-transform/\">Param Transform\u003C/a>.\u003C/p>\n\u003Ch2>When should you skip SSL proxying?\u003C/h2>\n\u003Cp>Three common cases.\u003C/p>\n\u003Ch3>1. Origin cert and Host do not play well\u003C/h3>\n\u003Cp>\u003Ccode>ERR_TLS_CERT_ALTNAME_INVALID\u003C/code> in this article. Put the host on Exclude; it becomes a normal HTTPS tunnel.\u003C/p>\n\u003Ch3>2. You never needed plaintext for that site\u003C/h3>\n\u003Cp>\u003Ccode>*.google-analytics.com\u003C/code>, \u003Ccode>*.example-cdn.com\u003C/code>—background noise. Exclude them to keep the capture list quieter.\u003C/p>\n\u003Ch3>3. The client pins certificates (or you simply must not MITM)\u003C/h3>\n\u003Cp>If an app should not be intercepted, or you do not need its HTTPS plaintext, tunnel that Host.\u003C/p>\n\u003Cp>Skip SSL proxying does \u003Cstrong>not\u003C/strong> “fix” pinning. It means you choose not to MITM that traffic.\u003C/p>\n\u003Ch2>Do not turn off SSL proxying for a handful of sites\u003C/h2>\n\u003Cp>If only \u003Ccode>admin.shop-example.com\u003C/code> is broken, do not disable SSL proxying globally. Do not turn off origin certificate checks just to paper over one host. That means the proxy stops seriously authenticating the real server.\u003C/p>\n\u003Cp>Keep both modes in one config:\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">Most hosts\n    ↓\nSSL proxy\n    ↓\nPlaintext capture\n\nA few special hosts\n    ↓\nSkip SSL proxy\n    ↓\nHTTPS tunnel\n\u003C/code>\u003C/pre>\n\u003Ch2>One sentence to keep\u003C/h2>\n\u003Cp>If: direct access works + SSL proxying makes that site fail + Host does not match the origin SAN → check \u003Cstrong>Skip SSL proxy (tunnel)\u003C/strong> first. Do not reinstall the CA. Do not kill all SSL capture.\u003C/p>\n\u003Cpre>\u003Ccode class=\"language-text\">Include\n   │\n   ├── no match → no SSL proxy\n   │\n   └── match\n        │\n        ├── Exclude match → tunnel\n        │\n        └── Exclude miss → SSL proxy\n\u003C/code>\u003C/pre>\n\u003Cp>Most HTTPS stays readable. A few odd hosts do not take the whole proxy down.\u003C/p>\n\u003Ch2>Next steps\u003C/h2>\n\u003Cp>Same proxy chain for API work:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Ca href=\"/en/docs/param-transform/\">Param Transform\u003C/a>: AES, Base64, and other field codecs\u003C/li>\n\u003Cli>\u003Ca href=\"/en/docs/map-route/\">Forward rules\u003C/a>: backend moved, frontend has not shipped\u003C/li>\n\u003Cli>\u003Ca href=\"/en/docs/mock/\">Mock\u003C/a>: fake responses without changing the server\u003C/li>\n\u003Cli>\u003Ca href=\"/en/docs/capture/\">Capture and request details\u003C/a>: HTTP / HTTPS / WebSocket\u003C/li>\n\u003C/ul>\n\u003Cp>If you only need this article’s fix: find the Host → exclude it in SSL proxy settings → refresh.\u003C/p>\n\u003Ch2>Next\u003C/h2>\n\u003Cp>\u003Cstrong>TBD: Breakpoints, resend, and collaboration on the proxy chain\u003C/strong>—more ways proxy tools get in the way during joint debug.\u003C/p>\n\u003Chr>\n\u003Cp>If SSL proxying has taken down a few sites for you too, \u003Ca href=\"/\">try DevPeek\u003C/a> and add an Exclude rule, or talk certs, CDNs, and proxy quirks on \u003Ca href=\"https://github.com/GYPengDev/devpeek/discussions\">GitHub Discussions\u003C/a>.\u003C/p>\n\u003Ch2>Related Docs\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"/en/docs/proxy-ssl/\">Proxy & SSL certificates\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/en/docs/faq/\">FAQ\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/en/docs/capture/\">Capture and request details\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/en/docs/quick-start/\">Quick Start\u003C/a>\u003C/li>\n\u003C/ul>\n\u003Ch2>Series\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"/en/blog/api-param-encryption-debug/\">H5 API Encrypted? Decrypt It On the Fly with DevPeek\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"/en/blog/mock-map-route-split-api/\">New API Is Live, Frontend Hasn't Shipped? Debug with Forward Rules\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","After Leaving Electron, Silent Updates Had to Be Ours","After the move to Tauri, electron-updater was gone and the stock updater didn't match Launcher, Core, and Shell. Checks and downloads moved into the tray; apply is a silent overwrite after you confirm. It ships in 1.3.0.","2026-08-28","DevPeek dev log: building our own silent updater after Electron. The tray checks and downloads in the background; a click runs a silent install. Windows / macOS in 1.3.0.","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","Why We Designed a WebSocket Mock DSL Instead of YAML, JSON, or JS","Lightweight WebSocket Mock shouldn't feel heavier than HTTP Mock. YAML, JSON, and JS all work—but they're wordy for connect, login, heartbeat. We built a short DSL to keep lightweight Mock light.","2026-08-13","DevPeek dev log: why WebSocket Mock uses a custom Flow DSL. YAML, JSON, and JS handle heavy cases; sequential lightweight scripts get a shorter text format.",{"slug":31,"title":32,"summary":33,"date":34,"featured":8,"seoDescription":35,"series":22,"seriesOrder":36},"dev-build-log-electron-to-tauri","DevPeek Architecture: Dropping Electron for Tauri","A debugging proxy shouldn't ship a whole Chromium just to open a window. We moved business logic into Core and swapped the desktop shell for Tauri—lighter installs, leaner background use, and the tray brings the UI back after you close the window.","2026-08-08","DevPeek dev log: moving the desktop shell from Electron to Tauri—business stays in Core, the shell handles windows and OS features, with smaller footprint and lower resource use.",2,{"slug":38,"title":39,"summary":40,"date":41,"featured":8,"seoDescription":42,"series":22,"seriesOrder":43},"dev-build-log-sqljs-to-better-sqlite3","Why We Moved Capture History from sql.js to Native SQLite","Early DevPeek stored captures in JavaScript-based SQLite (sql.js); busy sessions ate RAM and stuttered the list. Native SQLite keeps memory flat so the proxy can run all day.","2026-08-05","DevPeek dev log: moving capture storage from sql.js to native SQLite—fixing memory growth and list lag on all-day debugging sessions.",1,{"slug":45,"title":46,"summary":47,"date":48,"featured":8,"seoDescription":49,"series":10,"seriesOrder":36},"mock-map-route-split-api","New API Is Live, Frontend Hasn't Shipped? Debug with Forward Rules","After a service split, the frontend still hits the old API while orders already live on the new service. DevPeek Forward Rules forward specific endpoints to the new host without code changes; if the new service isn't ready, Mock gets the page working first.","2026-07-26","Microservice integration and API host migration: use DevPeek Forward Rules for API forwarding—point old-host requests to the new service without changing the frontend. Mock when migration isn't done. Includes a hands-on demo.",{"slug":51,"title":52,"summary":53,"date":54,"featured":8,"seoDescription":55,"series":10,"seriesOrder":43},"api-param-encryption-debug","H5 API Encrypted? Decrypt It On the Fly with DevPeek","Stuck with AES-encrypted API params during integration? Set the key and IV once in DevPeek Param Transform, and see plaintext automatically — you can even edit and re-encrypt on resend.","2026-07-18","Use DevPeek Param Transform to auto-decrypt AES-GCM encrypted H5 API requests. Supports two-way transform, plaintext editing, and debug replay.",{"slug":57,"title":58,"summary":59,"date":60,"featured":61,"seoDescription":62,"series":63,"seriesOrder":36},"h5-debug-console-mock","H5 Debug in Practice (2): Android WebView White Screen—From Console Remote Debug to Mock Validation","A campaign H5 white-screened on some Android devices after a button tap—all requests returned 200, but the page showed nothing. Using DevPeek Console to capture WebView runtime logs, remote eval to confirm a polyfill override, then Mock to verify the fallback UI under error conditions.","2026-07-13",true,"DevPeek H5 debug practice part 2: troubleshoot Android WebView white screen via Console remote debug to locate a JavaScript polyfill conflict, then use Mock to verify page fallback behavior under abnormal API responses.","h5-debug",{"slug":65,"title":66,"summary":67,"date":68,"featured":61,"seoDescription":69,"series":63,"seriesOrder":43},"wechat-h5-storage-debug","H5 Debug in Practice (1): WeChat H5 Local Cache—Debug It on Desktop","After switching test accounts in a WeChat official-account H5, the avatar still showed the old user—capture had the new token, stale data stayed in localStorage. This post walks through a real joint-debug case and how to view and edit localStorage, sessionStorage, and IndexedDB in WeChat WebView from your PC.","2026-07-11","DevPeek H5 debug: locate localStorage, sessionStorage, and IndexedDB cache issues in WeChat H5—compared with vConsole and remote debug, with real WebView debugging workflow.",{"slug":71,"title":72,"summary":73,"date":74,"featured":61,"seoDescription":75,"series":76,"seriesOrder":36},"why-we-built-devpeek-h5-debug","Why We Built DevPeek (2): That H5 Page in the App—Debug It on Your PC","Param transform fixed login, but the activity H5 only broke inside the App WebView. Remote debug and capture lived in different windows—so we folded mirroring and our own debug panels into DevPeek.","2026-07-10","DevPeek origin series, part 2: in-app H5 bugs that only show on real devices, the split between remote debug and capture, and how the Debug tab mirrors pages with built-in DOM, Console, and Network panels.","origin",{"slug":78,"title":79,"summary":80,"date":81,"featured":61,"seoDescription":82,"series":76,"seriesOrder":43},"why-we-built-devpeek","Why We Built DevPeek (1): HTTPS Decrypted, Body Still Gibberish","The night before a release, TLS was already open—but changing one request field still meant digging up encrypt/decrypt scripts. That pushed us toward a proxy tool with business-layer crypto built in—and DevPeek started there.","2026-07-09","DevPeek origin series, part 1: the manual request-body encrypt/decrypt grind—and why we set out to build a proxy tool that owns business-layer crypto.",1788161407711]