Developer environments most often create the illusion that “the browser is connected, but code still fails.” The usual reason is a different proxy scope: a browser extension manages only browser requests, a system proxy may not reach a container, and an IDE extension may use its own network stack. Trace outward from the process making the request rather than inferring from whether a web page opens.
Command line and local runtimes
First confirm which environment variables the terminal process reads, then check whether the SDK in use follows the system proxy. Some runtimes manage connection pools, certificates and DNS resolution themselves, so the presence of environment variables does not prove that requests use the intended route. For testing, use a minimal request without real credentials and identify whether the failure occurs during resolution, the handshake, authentication or response reading.
HTTPS_PROXY=http://localhost:PORT
AI_API_KEY=YOUR_API_KEY
run-your-command
IDE extensions and the integrated terminal
The editor’s main process, extension host and integrated terminal may have different environments. After changing the proxy, restart the relevant processes and review the extension logs again. If code completion works but chat does not, different features may use different APIs. If every request fails, prioritize editor-level proxy settings, certificates and network permissions.
CI and automation jobs
CI runners usually do not inherit the network environment of a development computer. Configure the outbound path explicitly on the runner, and store keys using the project’s secret-variable feature. Do not print complete request headers, subscription details or access credentials in logs. If the job retries, distinguish network failures from business errors returned by the platform to avoid retrying invalid requests.