Browsers, SDKs and servers may use different exit routes
Browser pages usually use the browser’s or system’s network settings, while API requests are sent by the process running the SDK. Local scripts, containers and remote servers don’t necessarily inherit the desktop client’s proxy. If web chat works but a script times out, first find out where the script is running, then check that environment’s DNS, proxy settings and access to the target domain.
Web subscriptions, API keys, project limits and model permissions may also be separate. For authentication failures, check the key’s project and permissions. For exhausted limits, check billing and usage. If a model is missing or inaccessible, consult the API documentation. Focus on the connection path only when you see issues such as failed connections, DNS resolution errors or repeated response interruptions.
Streaming Requests Must Be Read to Completion
Streaming output depends on the client, proxy, intermediate gateway and server working together. If a script quickly times out while the web app completes the response, check the SDK timeout, how the stream is read and whether an intermediate gateway buffers responses. Avoid switching routes before generation finishes, and don’t turn a temporary network issue into platform rate limiting with rapid retries.
Store keys in controlled environment variables or a secrets manager. Don’t put them in frontend pages, shared repositories or public logs. When troubleshooting requests, log only necessary status and error types, and redact prompts, attachments and credentials. You don’t need to share a full key with any route provider to diagnose network issues.