Postman sets a proxy in a different place from where most people look for it, and it applies the setting more broadly than they expect. There is no per-request proxy field on the request builder. The proxy lives in the application settings and, once set, routes every request the app sends. This guide covers proxies with Postman end to end: the custom proxy configuration, the system proxy, authenticated proxies, why the desktop agent matters, SOCKS, running a proxied collection from the command line with Newman, and verifying the exit IP so you know it took effect.
We run a proxy network and a live proxy checker, so the Postman proxy question we field most is why a proxy set somewhere on the request has no effect. The answer is that Postman does not take a proxy on the request at all. It takes one in Settings, and there it applies to everything. Where a request needs a live proxy, pull a fresh one from our free proxy API, which returns recently checked endpoints with no key.
How do you set a proxy in Postman?
Open Settings, select the Proxy tab, and choose one of two options. Turn on Use the system proxy to inherit whatever your operating system is configured to use, or tick Add a custom proxy configuration and enter the proxy server host and port. The custom option is the one you want for a specific proxy, because it does not depend on OS settings and it is explicit about which endpoint you are testing.
The important thing to understand is scope: this setting is app-wide. Every request in every collection goes through it until you turn it off. Postman is a client for exercising APIs, not a scraper, so it configures the proxy once for the whole app rather than per request.
The custom proxy configuration, field by field
In Add a custom proxy configuration you set:
- Proxy server, split into the protocol (HTTP or HTTPS), the host, and the port. For a plain HTTP proxy carrying HTTPS traffic, leave the protocol on HTTP and let the proxy tunnel HTTPS through
CONNECT, which is the normal, correct combination. - Proxy auth, a toggle that reveals a username and password field. Enable it for a paid proxy and Postman sends the
Proxy-Authorizationheader for you.
There is also a proxy bypass list. Anything matching it skips the proxy and goes direct, which is useful for a local development server but a trap if a bypass rule accidentally covers your real target and quietly sends that traffic on your own IP.
Request builder
no proxy field here
Settings, Proxy tab
custom or system proxy
Applies app-wide
every request routes through it
Desktop agent
the one that can honor it
The desktop agent matters
Postman sends requests through an "agent", and which one you use decides whether a proxy can work at all. The browser agent runs inside your browser and is bound by the browser's own network rules, so it cannot route through an arbitrary proxy. The desktop agent (the Postman desktop app, or the standalone agent behind the web app) makes the request itself and can honor your proxy configuration. If a proxy set in Settings appears to do nothing, the request is almost always going out through the browser agent. Switch to the desktop agent and the setting takes effect.
Authentication and the 407
With Proxy auth enabled and the username and password filled in, Postman answers the proxy's challenge automatically. A wrong or missing login comes back as HTTP 407 Proxy Authentication Required, which is oddly reassuring: it proves the proxy is alive and reachable, and only the credentials are wrong. If Postman shows a 407 even with the fields filled, confirm the exact same user:pass@host:port works in curl:
curl -x http://user:pass@HOST:PORT --max-time 10 https://httpbin.org/ip
If curl succeeds and Postman does not, the problem is Postman's agent or bypass list, not the proxy.
SOCKS proxies
Postman's custom proxy configuration is aimed at HTTP and HTTPS proxies. For SOCKS, the practical routes are to set a SOCKS proxy at the operating-system level and let Postman use the system proxy, or to move the job to Newman in a shell that exports ALL_PROXY=socks5://host:port. For most API testing an HTTP proxy is all you need, so reach for SOCKS only when the endpoint or the network genuinely requires it.
Running a proxied collection with Newman
The clean way to run a proxied Postman collection unattended, in CI or a cron job, is Newman, the Postman command-line runner. Newman honors the standard proxy environment variables, so no in-app setting is involved:
# route the whole run through the proxy
HTTPS_PROXY="http://user:pass@203.0.113.7:8080" \
HTTP_PROXY="http://user:pass@203.0.113.7:8080" \
newman run my-collection.json --environment prod.json
Because it is environment-variable driven, Newman is also where a rotating pool fits: wrap the run in a shell loop that exports a different proxy each time, or point it at a rotating gateway that returns a fresh exit per request. Our free proxy API returns a plain-text pool you can pull into that loop for testing.
Verify the exit IP
Never assume the proxy took effect. Point a request at an IP echo and read the address Postman reports:
GET https://httpbin.org/ip
Run it once with the proxy off and once with it on. If the origin address does not change, the proxy is not routing you, which in Postman almost always means the request is on the browser agent or the custom proxy is toggled off. For a fuller check of the exit, our proxy checker reports the exit IP, country, latency and anonymity grade in one paste, which is quicker than scripting those checks into a collection.
Where to go from here
Postman's proxy model is one setting in the wrong place from where instinct sends you, plus the desktop-agent detail that decides whether it works at all. Once those are muscle memory, the discipline is the same as any proxied client: verify each exit, and pull from a pool that is alive.
The cURL guide is the shell-side reference for the one-line checks above, proxies for web scraping covers choosing the right proxy type once you move past testing, and how to check if a proxy is working is the full verification method. When an API workflow graduates from testing in Postman to running against a real target, a rotating gateway that returns a fresh residential IP per request at $0.44/GB is what keeps it from being rate-limited on a single address.