Proxy works in a browser but fails in code

Start with a small comparison matrix

A browser and a script can differ in proxy configuration, DNS resolution, connection reuse, HTTP behavior, cookies and the request itself. Changing all of these together may produce a successful request, but it will not tell you which change mattered.

Start with a controlled endpoint that you own, or an IP-echo service suitable for a small diagnostic request. Compare direct access, curl through the proxy, Requests through the proxy and a browser through the proxy. Record success, status, elapsed time and observed exit IP. Keep passwords and authorization headers out of the report.

Check the proxy URL and authentication

The scheme in a proxy URL describes how the client talks to the proxy. An HTTPS destination can use an HTTP proxy via CONNECT; that does not mean the proxy URL should automatically begin with https://. Use the protocol and port supplied for the product.

Characters such as @, : and / in a username or password need correct encoding when embedded in a URL. Prefer a library's explicit credential fields where available. Do not solve a certificate error by turning off TLS verification: establish which certificate and connection failed.

import os
import requests

proxy = os.environ["MP_PROXY_URL"]
target = os.environ.get("MP_TEST_URL", "https://api.ipify.org?format=json")

with requests.Session() as client:
    # Make this diagnostic independent of HTTP_PROXY / HTTPS_PROXY.
    client.trust_env = False
    response = client.get(
        target,
        proxies={"http": proxy, "https": proxy},
        timeout=(10, 20),
        allow_redirects=False,
    )
    print("status:", response.status_code)
    # Inspect the response privately; never print proxy credentials.
    response.raise_for_status()

Inspect environment and bypass rules

Requests can use proxy environment variables by default. A local shell, an IDE and a scheduled job may inherit different values. NO_PROXY can exempt a destination, while another client's configuration may ignore the environment completely.

For a diagnostic comparison, set the proxy explicitly and document environment handling. Restore the application's intended configuration afterward. If a corporate environment requires its own trust store or network route, use that approved configuration rather than disabling verification.

• Check both lowercase and uppercase proxy environment settings.
• Check NO_PROXY entries and application-specific bypass lists.
• Confirm that the process was restarted after configuration changes.
• For SOCKS, check whether DNS resolution is local or delegated to the proxy.

Separate connectivity from the target response

A 407 response concerns proxy authentication. A 403 or 429 returned by the destination is a different layer: the connection may have worked, but the destination refused or limited the request. A timeout before receiving any HTTP response is different again.

A browser may run JavaScript and retain a valid session while a simple HTTP client does neither. TLS and HTTP protocol behavior can also differ. These are hypotheses to test separately, not a reason to declare every failure a fingerprint issue or a guarantee that a different proxy will resolve it.

Respect the destination's access rules. For systems you own, server logs and a minimal reproducible request are more useful than repeatedly rotating addresses around a failure.

Keep a reproducible failure report

1. Record the client and version, proxy protocol and affected destination.
2. Confirm whether a neutral endpoint returns the intended exit address.
3. Record the error class or HTTP status and when it occurred.
4. Remove credentials, cookies and authorization headers before sharing logs.
5. Change one setting at a time and repeat the same request.