The Website Works, but the API May Still Fail
Web pages usually use the browser’s or system’s proxy route. API requests are sent by an SDK, runtime or separate process, which may not inherit browser settings. Platforms may also have different authorization, usage limits and regional rules for web and API access. First confirm you’re calling the official API and check your account’s eligibility for it. Then verify that requests use the expected network exit.
Command-Line Tools and SDKs
Check whether your SDK reads HTTPS_PROXY or HTTP_PROXY, or supports an explicit proxy setting. Behavior varies by runtime, so don’t assume an environment variable takes effect just because you set it. Use the local address and port shown in your VPNDisc client; don’t copy someone else’s port, and don’t enter a subscription link as a proxy address.
After changing settings, restart the relevant process and send a minimal request without sensitive business data. Note the error type and when it occurs: DNS resolution failures, connection timeouts, authentication failures and insufficient usage limits need different fixes. Once the test succeeds, restore streaming and your full request parameters.
IDE Plugins and Remote Workspaces
The editor’s main process, extension host and integrated terminal may use different settings. Check the IDE and plugin proxy documentation, then restart the relevant processes after making changes. In a remote workspace or container, requests may run remotely. A connected local client doesn’t prove the remote network has changed.
CI and Automated Jobs
CI runners don’t inherit your personal computer’s system proxy. Configure an authorized network exit in the runner’s environment and confirm the platform allows that region and usage. Store keys in the task platform’s secret variables rather than writing them to logs. Don’t disable certificate verification to fix a TLS error; check the system clock, trusted certificates and corporate network policies instead.