Developer Proxy Examples

Verified proxy compatibility: versions and test conditions

These results help you choose a client configuration to reproduce. We executed the named libraries and examples against local HTTP and SOCKS5 protocol fixtures that never forwarded traffic to the internet. They verify the listed local configurations, not routing through BuyProxies infrastructure or acceptance by your target website. Original five-client qualification: 12 October 2026. The separately dated Node.js supplement below was qualified on 14 October 2026.

“Verified” means the expected behavior was observed in the controlled test. “Not tested” means unknown in this qualification. On a narrow screen, focus the table area and scroll horizontally to read all columns. Dates below are UTC.

What the tests include

All five clients received the expected success response and rejected wrong proxy credentials and an untrusted TLS certificate. Destination 403 responses were distinguished from proxy-authentication failures. Requests, HTTPX, aiohttp and Scrapy also observed a first 302 response without following it. The aiohttp example reports that response as redirect_response; a redirect is not proof of a broken proxy. Scrapy checks included one bounded 503 retry, fixture pool selection and robots.txt exclusion. n8n preserved and exercised the workflow’s 30000 ms timeout.

Configuration and qualification limits

Certificate and hostname verification stayed enabled. Temporary fixture CAs were supplied only to the test processes; successful TLS requests did not disable verification. HTTPS through CONNECT means an HTTPS destination reached through a plain HTTP proxy. A TLS connection to the proxy itself was not tested. HTTPX and aiohttp used official pure-Python wheels imported as ZIPs; Scrapy used ZIP namespace loaders, pure-Python zope.interface and checked compression-extension aliases. These loading conditions are part of the qualification.

Requests used PySocks 1.7.1 with socks5h; a domain-name SOCKS request was observed, but external DNS resolution was not measured. HTTPX used socksio 1.0.0. SOCKS was not tested for aiohttp, Scrapy or n8n. IP allowlisting, remote exit IPs, speed, uptime, other client versions and your destination’s access policy were not qualified. Reproduce a small request from the actual deployment before relying on the configuration.

Official configuration references

• Requests proxies: HTTP proxy URLs, proxy authentication and optional SOCKS support. The documented socks5 and socks5h schemes differ in where DNS is resolved.
• HTTPX proxies: the proxy parameter, URL credentials and the optional SOCKS dependency.
• aiohttp proxy support: HTTP proxies, CONNECT and authentication; version 3.14 deprecates proxy_auth in favor of explicit proxy headers.
• Scrapy HttpProxyMiddleware: per-request proxy configuration and handler-dependent support. The tested HTTP/1.1 handler must not be treated as a qualification of the separate HttpxDownloadHandler.
• n8n HTTP Request node: the explicit HTTP Proxy option and timeout setting. This local CLI result does not qualify n8n Cloud.

Download the original five-client compatibility matrix, 12 October 2026 (JSON) for the exact versions, example hashes, dates, controls and limitations. The file contains no proxy endpoints or credentials.

Node.js supplement: 14 October 2026

The following three request paths were executed on Windows with Node.js 24.17.0 against non-forwarding local HTTP/HTTPS services and an authenticated HTTP proxy fixture. They add 30 request controls and two separately labelled native-agent diagnostics. They do not extend the SOCKS or external-exit claims of the original five-client matrix.

Each request client was checked for HTTP and HTTPS success, wrong authentication, an untrusted target certificate, target 403, a same-fixture redirect and its unchanged 30-second timeout. TLS verification stayed enabled; the fixture CA was added to child-process trust alongside normal Node roots; the untrusted-certificate controls omitted it. Four original Axios error controls exposed synthetic authentication in process output; the corrected example passed all eight controls without it. Those original observations are retained.

The two distinct native-agent diagnostics observed IPv4 dash-range bypass in the native HTTP agent and no HTTP_PROXY fallback in the native HTTPS agent. Built-in fetch and imported EnvHttpProxyAgent did fall back to HTTP_PROXY when HTTPS_PROXY was absent. SOCKS, HTTPS proxy transport, other versions, physical phones, real exit IPs and throughput were not tested. The POSIX startup commands were checked through Windows process environment/flag equivalence; Linux/macOS shell syntax was not executed.

Read the corrected Node.js examples and dated runtime note, or download the separate anonymous Node.js compatibility supplement (JSON). The original five-client JSON and evidence ZIP remain the dated 12 October artifacts.