Why a Proxy Works on One Website but Not Another
Separate a working proxy connection from destination restrictions, port rules, TLS errors, and HTTP responses.
Keep the proxy configuration unchanged when one website works and another does not. The difference between those requests is useful evidence; changing the endpoint immediately throws it away.
For HTTPS through an HTTP proxy, distinguish the CONNECT response, destination TLS and the website's final HTTP response in the client trace:
| Observed failure | What to inspect |
|---|---|
| No proxy response | The proxy connection and route. A previously successful site does not establish current availability. |
| CONNECT denied for one target | Allowed destination/port policy and reachability from the proxy's network. |
| Tunnel accepted, certificate verification fails | The reported certificate error: expiry, hostname, local clock, trust configuration or managed interception. |
| Verified TLS followed by website 403 | The website's access rules, account state, required cookies and permissions. |
| Website 429 | Published rate limits. Other users can contribute activity attributed to a shared exit. |
Read who produced an error page. An intermediary can return a 403 or another HTTP error; the number alone does not locate it. Keep TLS verification enabled so a request that appears to succeed does not hide the secure-connection failure.
For each target, record the proxy-handshake result, TLS result and final status. Include an ordinary destination you control as a baseline. If the endpoint reaches that baseline but one website consistently rejects its exit address, investigate the website's requirements or use another permitted route. Changing proxies cannot satisfy missing authentication or access permissions.