test/curl fails when connected to VPN #195
Description
[ RUN ] CurlTest.HttpGetRequest
Attempt 1 failed: Response doesn't appear to be HTML. Retrying... (2 attempts remaining)
Attempt 2 failed: Response doesn't appear to be HTML. Retrying... (1 attempts remaining)
/Users/smanders/Code/pros/buildpro/test/curl.cpp:122: Failure
Value of: success
Actual: false
Expected: true
Failed after 3 attempts. Last error: Response doesn't appear to be HTML
/Users/smanders/Code/pros/buildpro/test/curl.cpp:125: Failure
Expected: (response.find("<html")) != (std::string::npos), actual: 18446744073709551615 vs 18446744073709551615
Response doesn't appear to be HTML
[ FAILED ] CurlTest.HttpGetRequest (4212 ms)
[ RUN ] CurlTest.HttpsRequest
/Users/smanders/Code/pros/buildpro/test/curl.cpp:149: Failure
Expected: (response.find("<html")) != (std::string::npos), actual: 18446744073709551615 vs 18446744073709551615
Response doesn't appear to be HTML
[ FAILED ] CurlTest.HttpsRequest (354 ms)
Windsurf Cascade response
When you’re on VPN, your outbound HTTP/HTTPS traffic often isn’t going directly to the public internet anymore. It may be:
- routed through a corporate proxy,
- intercepted by a security gateway (SSL/TLS MITM),
- subject to DNS rewriting / split-DNS,
- blocked/filtered for certain destinations,
- redirected to an authentication/captive-portal page,
- or transparently forced to a “block page” that isn’t HTML (sometimes JSON, plain text, or an error blob).
Your curl_test is failing specifically because the response body doesn’t contain "<html", which strongly suggests you’re getting some other content (or possibly nothing) under VPN.
Most common reasons
- Proxy/intercept returns a non-HTML response
Many VPN/proxy stacks return:
- plain text error pages,
- JSON error objects,
- or an HTML page that doesn’t include lowercase
<html(could be<HTML>, or HTML fragment).
Your test is brittle because it checks for a literal substring rather than HTTP status/content-type.
- HTTPS MITM/certificate inspection
If your VPN does TLS inspection, it may:
- present a corporate root CA,
- or block TLS if it can’t inspect it.
Depending on your libcurl build options and trust store, you might get:
- a successful connection but to an internal gateway page,
- or a failure that your code may be surfacing as “success=false”.
-
DNS changes under VPN
Under VPN,example.commight resolve differently (or fail/resolve to an internal sinkhole). You may be connecting to the wrong host and getting something unexpected. -
Redirect to login / SSO portal
Some VPN configurations redirect unauthenticated HTTP requests to a login portal. That page might be HTML, but could also be a minimal response, JS-only, or compressed in a way your code doesn’t handle as expected.
How to confirm quickly
Look at what you’re actually receiving (status code + headers + first bytes of body). If you run the equivalent with the CLI:
curl -v http://<same-url-as-test>
curl -v https://<same-url-as-test>
Things to check:
- HTTP status (200 vs 3xx vs 4xx/5xx)
Content-TypeLocationheader (redirects)- Body (is it an error message, JSON, etc.)
Also check whether you have proxy env vars set under VPN:
http_proxy,https_proxy,ALL_PROXY,no_proxy
What this implies for the test
The test is currently asserting “internet works and returns HTML”. That’s not a stable invariant across VPN/proxy environments.
Better assertions (if you decide to harden it):
- check for a 200 OK and a reasonable
Content-Type, - or use a controlled internal endpoint,
- or relax the body check (case-insensitive
<html, or check status code only), - or explicitly configure proxy behavior in the test (honor env vars / allow skipping).
If you paste the URL used in test/curl.cpp and (under VPN) the HTTP status + Content-Type you get from curl -v, I can tell you which of the above is happening with high confidence.