[miguel-heygen]

What changes

The capture docs now say that capture needs direct internet access and does not use HTTPS_PROXY or HTTP_PROXY.

Since 0.8.164 (#5668), Chrome's traffic goes through capture's own proxy, which dials each checked public address directly. Where the only way out is a proxy (some sandboxes and corporate networks), every page fails with net::ERR_TUNNEL_CONNECTION_FAILED, while curl through the same proxy succeeds.

Why docs, not code

Routing capture through the environment's proxy would loosen the public-address guard #5668 added. The decision is to keep that guard and document the requirement.

Verified

Reproduced in a network namespace whose only way out is an HTTPS proxy:

• curl https://example.com through the proxy: 200;
• capture https://example.com on 0.8.164 to 0.8.166: fails with net::ERR_TUNNEL_CONNECTION_FAILED;
• the same capture on 0.8.163: succeeds, and the proxy logs Chrome's CONNECT example.com:443.

format:check passes.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
hyperframes	🟢 Ready	View Preview	Oct 17, 2026, 3:32 AM

💡 Tip: Enable Automations to automatically generate PRs for you.

[somanshreddy]

Reviewed at 1b7d0930. No blocker. Docs only, +6 lines.

The new paragraph matches the behavior the body reproduces. Since #5668 (0.8.164), capture's own proxy dials each checked public address directly and ignores HTTPS_PROXY/HTTP_PROXY, so a proxy-only network fails with net::ERR_TUNNEL_CONNECTION_FAILED. Documenting it instead of routing through the environment's proxy is the right call, because routing would weaken #5668's public-address guard.

— Somu