Our stake: we are Geonode and we sell proxies, so the first half of this article is about using our kind of product with Postman. The honest note is that Postman is a poor tool for proxy-heavy work — it applies proxy settings globally rather than per request, so you cannot easily send one request through a proxy and another directly. It is excellent for testing whether a proxy works and for exploring an API through one; it is the wrong tool for a workload that needs different routing per call. Use it to verify your configuration, then move the actual work to a client that gives you per-request control.
Which Feature Do You Want?
Decide this first and the rest is straightforward.
You want Postman to send your requests through a proxy. Reasons: a corporate proxy is the only route out of your network, or you are testing an API through a proxy to check geolocation or access. This is the global proxy configuration, covered next.
You want to capture requests from another application. Reasons: seeing what a mobile app or a browser actually sends, or debugging a third-party integration. This is Postman's built-in proxy, covered later. Postman becomes the intermediary and other software points at it.
They are configured in different places and solve unrelated problems.
Configuring a Global Proxy
Postman's documentation describes three approaches.
Default proxy uses your system's configured proxy automatically. If your operating system already has one set, Postman picks it up and you need do nothing.
System proxy explicitly enables the system proxy for requests, which is the setting to check when you have a system proxy configured and Postman appears to be ignoring it.
Custom proxy lets you specify a different server. This is the one to use for a commercial proxy service, and it is set in Settings under the Proxy tab.
Supported protocols are broader than people expect. The documentation lists "HTTP, SOCKS5, SOCKS5H, SOCKS4, and SOCKS4A protocols", with one limitation stated plainly: "Postman only supports sending HTTP and HTTPS requests through a SOCKS proxy."
That SOCKS5H entry is worth noticing. The h variant sends the hostname to the proxy for resolution rather than resolving locally, which prevents DNS queries leaking to your own resolver while your traffic exits elsewhere. If you are using SOCKS specifically to change where you appear to be, choose SOCKS5H rather than SOCKS5.
Authentication is a separate toggle. For a proxy requiring credentials, the documentation says to "add the credentials to the Postman desktop app" by entering a username and password in the Proxy settings tab. Note that this is the desktop app — the browser version cannot reach a proxy on your local network.
The bypass list lets you exclude hosts: "enter a comma-separated list of hosts. Requests sent to these hosts won't use the custom proxy." Put localhost, 127.0.0.1 and any internal hostnames here, or requests to your own development server will be routed out through the proxy and fail confusingly.
Verifying It Actually Works
The step people skip, and the one that saves an hour.
Send a request to a service that reports the address it sees:
GET https://api.ipify.org?format=json
Run it with the proxy disabled, note the address, then enable the proxy and run it again. If the address does not change, the proxy is not being used. There will be no error message telling you this — the request simply goes directly and succeeds.
Three common reasons it does not take effect:
The bypass list matches your target. Check for an entry that unintentionally covers it.
You are using the browser version of Postman, which cannot reach a proxy on your machine. The desktop app is required.
The setting is on the wrong tab. Default, system and custom are separate options, and configuring a custom proxy while the system proxy option is selected does nothing.
For geo-targeted proxies, checking the address is not sufficient. Verify by outcome — request something that genuinely differs by region and confirm the response changes. A lookup service reporting the right country while your API returns your home region's data means the targeting is not landing where it matters.
The Settings That Break Requests
Two Postman settings interact with proxy use and cause confusing failures.
SSL certificate verification. If your proxy intercepts TLS — which corporate proxies commonly do — Postman will reject the certificate because it was issued by the proxy's own authority rather than a trusted one. The symptom is a TLS error on every HTTPS request.
The correct fix is to add your organisation's CA certificate in Postman's certificate settings. The tempting fix is to turn off SSL verification globally, and it is worth understanding what that costs: every request in Postman then accepts any certificate, including on APIs where you would very much like to know if something is intercepting you. If you must disable it, do so knowingly and turn it back on afterwards.
Request timeouts. Postman's default request timeout is generous, but a proxy — particularly a residential one — adds real latency per request. If requests through a proxy time out while the same requests work directly, raise the timeout in settings before concluding the proxy is broken.
A related note on collection runs: through a metered proxy, a collection run with a large data file makes one request per row and you pay for every one. That is obvious in hindsight and surprising on an invoice.
Postman's Built-in Proxy: Capturing Traffic
The other feature, and a genuinely useful one.
The documentation describes it directly: "The Postman desktop app has a built-in proxy that can capture HTTP and HTTPS traffic." It intercepts requests from client applications, forwards them on, captures the responses, and can collect cookies as well.
The default port is 5559.
To point another device at it, the documentation sets out three steps: find your computer's local IP address, configure the device's wireless settings to use an HTTP proxy with that IP and the proxy port, and — for iOS specifically — go to Settings, Wi-Fi, the info icon, Configure Proxy, Manual, then enter the server IP and port.
This is the fastest route to answering "what is this mobile app actually sending", which is otherwise a surprisingly awkward question.
HTTPS requires a certificate. The documentation is explicit that the proxy "requires installing the postman-proxy-ca.crt certificate on client devices to capture secure HTTPS traffic", and that on the host computer, "installing the certificate enables the Postman proxy to capture secure HTTPS traffic sent from browsers and other client apps".
Understand what that means before doing it. You are installing a certificate authority that can issue certificates for any domain, and Postman then decrypts your TLS traffic in order to show it to you. That is the entire mechanism — there is no way to inspect encrypted traffic without terminating the encryption.
Two consequences worth taking seriously. Remove the certificate when you have finished, particularly on a phone you use for anything personal. And do not capture traffic containing credentials you care about while the certificate is installed, because those credentials are being decrypted and displayed.
Using Environments to Manage Proxy-Dependent Work
Since Postman cannot vary the proxy per request, the practical workaround is to vary everything else — and its environment feature is well suited to it.
Put the target base URL in an environment variable, not in the request. A collection whose requests all use {{baseUrl}} can be pointed at a different host by switching environments, which is how you compare behaviour across regions without editing anything:
{{baseUrl}}/api/products?region={{region}}
Create one environment per scenario. A "direct" environment and a "via proxy" environment, each with its own variables, lets you switch context in one dropdown. You still have to toggle the proxy setting itself in Settings, but everything else moves with the environment.
Store the address check as a request in the collection. A GET https://api.ipify.org?format=json saved alongside your real requests means confirming the proxy takes one click rather than a fresh tab. Add a test script so it records what it found:
const ip = pm.response.json().ip;
pm.environment.set("observedIp", ip);
console.log("Exit address:", ip);
Assert on region-dependent content, not on the address. For geo-targeted work, the useful check is whether the response actually differs:
pm.test("Response is region-specific", function () {
pm.expect(pm.response.json().currency).to.eql(pm.environment.get("expectedCurrency"));
});
This is the same principle as everywhere else in proxy work: an IP lookup tells you what the lookup service thinks, and only the target's own response tells you whether the targeting worked.
And keep credentials out of the collection. Proxy credentials belong in Postman's settings, and API credentials belong in environment variables marked as secret — not in the request, and certainly not in a collection you intend to export or share. An exported collection carries its variable values with it unless they are marked secret, which is an easy way to publish a token by accident.
Which Client for Which Job
Postman is a good tool with a specific shape, and knowing where it stops saves time.
Use Postman for: exploring an API interactively, checking whether a proxy works at all, capturing traffic from a device, and sharing a request collection with colleagues.
Use curl for: anything you want to reproduce, script or paste into a ticket. Per-request proxy control with -x, verbose output showing exactly what went on the wire, and a command that works identically on any machine:
curl -x http://user:pass@proxy.example.com:9000 https://api.ipify.org
Postman can generate a curl command from any request, which is the fastest way to move from exploration to something reproducible.
Use a proper HTTP client in code for: anything with real volume, per-request routing, retry logic or session handling. Postman's global proxy setting is a single value for the whole application, so a workload needing different exits per request cannot be expressed in it at all.
A practical workflow: verify the proxy works in Postman, export the request as curl to confirm it outside the GUI, then implement it in code with per-request control. Each step is faster than debugging the previous one in the wrong tool.
Troubleshooting
Requests work without the proxy and fail with it. Check credentials first — a 407 status means the proxy rejected you, and it is a different failure from a 401 coming from the target. Then check whether your provider uses an IP allowlist that your current address is not on.
Everything is slow. Residential proxies add genuine per-request latency, and that is physics rather than a fault. Raise the timeout and measure before concluding anything is broken.
TLS errors on every HTTPS request. The proxy is intercepting TLS. Add the CA certificate rather than disabling verification.
The proxy setting appears to be ignored. Check the bypass list, check that you are on the desktop app, and confirm you enabled the right option — custom, system and default are separate.
Capture shows nothing. Confirm the device is on the same network, the port matches, and no firewall on your machine is blocking inbound connections on 5559.
HTTPS capture shows connections but no content. The CA certificate is not installed or not trusted on the client device. On some platforms, installing a certificate and trusting it are separate steps.
A 407 that persists with correct credentials. Check for characters in the password that need encoding, and confirm whether your provider expects credentials at all — many offer IP allowlisting instead, which removes the credential from the configuration entirely and is worth using where your address is stable.
People Also Ask
How do I set a proxy in Postman?
In the desktop app, open Settings and go to the Proxy tab, then choose a custom proxy and enter the host and port. Postman also supports using the system proxy automatically. Add credentials in the same tab if the proxy requires them.
Does Postman support SOCKS proxies?
Yes — the documentation lists HTTP, SOCKS5, SOCKS5H, SOCKS4 and SOCKS4A. The stated limitation is that only HTTP and HTTPS requests can be sent through a SOCKS proxy. Prefer SOCKS5H over SOCKS5, since it resolves hostnames at the proxy and avoids leaking DNS queries.
Why is Postman ignoring my proxy settings?
Usually one of three things: the target host matches an entry in the bypass list, you are using the browser version rather than the desktop app, or you configured a custom proxy while a different proxy option is selected. Verify by requesting a service that reports your address.
How do I capture requests with Postman?
Use the built-in proxy, which defaults to port 5559. Find your computer's local IP, configure the client device to use it as an HTTP proxy on that port, and install the postman-proxy-ca.crt certificate on the device if you need to capture HTTPS.
Why do I get SSL errors when using a proxy in Postman?
Because the proxy is intercepting TLS and presenting its own certificate, which Postman does not trust. Add your organisation's CA certificate in Postman's certificate settings. Disabling SSL verification works and applies to every request thereafter, which is a meaningful cost.
Can I set a different proxy per request in Postman?
No. The proxy setting is application-wide, which is the main reason Postman is unsuited to workloads needing different exits per request. Use a code-based client for that, and use Postman to verify the proxy works before you write it.
What is the difference between Postman's proxy settings and its capture proxy?
The proxy settings route Postman's own requests through an external proxy. The capture proxy makes Postman act as a proxy that other applications send requests through, so you can see what they transmit. Opposite directions, unrelated configurations.
Is it safe to install the Postman CA certificate?
It is a deliberate trade-off. The certificate lets Postman decrypt your HTTPS traffic, which is the only way to inspect it — and it means anything with that certificate can issue trusted certificates for any domain. Install it when you need capture, remove it when you are finished, and avoid handling sensitive credentials while it is in place.
Wrapping Up
The confusion in this topic is entirely a naming problem. Postman's proxy settings send your requests through someone else's proxy; Postman's capture proxy makes Postman the intermediary for other applications. Deciding which you want takes ten seconds and saves you reading the wrong documentation.
For the first, use the desktop app, set a custom proxy in Settings, put localhost in the bypass list, and — the step that matters — verify by requesting a service that reports your address, because a proxy setting that does nothing produces no error at all.
For the second, port 5559 and a CA certificate on the client device. Understand that the certificate exists so Postman can decrypt your traffic, and remove it when you are done.
And recognise where Postman stops. It applies proxy settings globally, so it cannot express per-request routing at all. Use it to confirm a proxy works, export the request as curl to check it outside the GUI, and then build the real thing in code — which is faster than trying to make an interactive tool do a scripted job.