How to Configure and Test Proxies in Postman

Understand the four Postman proxy concepts

Postman’s current Proxy settings reference states that system proxy and environment variable options are enabled by default in current releases. Inspect all toggles before blaming a private endpoint.

Configure a custom private proxy

1. Open the Postman desktop app and select Settings.
2. Open the Proxy tab.
3. Disable the system proxy option if the custom proxy must take precedence.
4. Enable custom proxy configuration.
5. Select HTTP, SOCKS5 or the protocol supplied by the provider.
6. Enter hostname or IP and port in their dedicated fields.
7. Enable proxy authentication and enter username/password when required.
8. Add narrow bypass hosts for local or internal services that should connect directly.
9. Save the settings and send a controlled IP-check request.

Postman documents support for HTTP, SOCKS5, SOCKS5H, SOCKS4 and SOCKS4A in custom settings, while noting that SOCKS is used to send HTTP and HTTPS requests. Select the real proxy protocol, not the protocol of the destination URL.

Use the proxy formatter when converting a provider string into separate host, port, username and password fields. Do not paste user:password@host:port into the hostname box.

Verify the Postman proxy route

Create a request such as GET https://api.ipify.org?format=json and send it after saving the proxy settings. The response should show the proxy exit, not the normal office or home IP. Compare that address with the assigned endpoint and check its location if the API scenario is regional.

Then test the actual authorized API with the same proxy. Record the Postman request name, environment, proxy mode, masked proxy ID, observed exit, status, response time and any error. Do not export an environment that contains proxy or API passwords.

• The IP endpoint returns the expected exit.
• The target API status and body match the test contract.
• Proxy authentication succeeds without exposing credentials.
• Bypass hosts connect through the intended route.
• Regional response fields match the selected test case.
• Console and shared logs contain no secrets.

The API testing proxy guide explains how to separate proxy transport, target HTTP response and schema validation.

Use HTTP_PROXY, HTTPS_PROXY and NO_PROXY

Postman can respect operating-system proxy environment variables. This is convenient in managed development environments but can create hidden configuration when the desktop app is launched outside the shell where variables were set.

# PowerShell
$Env:HTTP_PROXY = "http://proxy.example:8080"
$Env:HTTPS_PROXY = "http://proxy.example:8080"
$Env:NO_PROXY = "localhost,127.0.0.1"

# Linux or macOS
export HTTP_PROXY="http://proxy.example:8080"
export HTTPS_PROXY="http://proxy.example:8080"
export NO_PROXY="localhost,127.0.0.1"

Restart Postman after changing the process environment and confirm whether the application was launched from that environment. When debugging, temporarily choose one configuration path instead of leaving system, custom and environment settings enabled together.

Credentials inside environment URLs can be exposed in shell history, process diagnostics or support screenshots. Prefer the desktop app’s protected authentication fields or your organization’s approved secret mechanism. The proxy authentication guide compares basic credentials and IP allowlisting.

TLS certificates and HTTPS APIs

An HTTP proxy can carry HTTPS requests through CONNECT without making the destination HTTP. If an organization intentionally inspects TLS, the workstation must trust the approved certificate authority. A certificate name, expiration or trust failure should be diagnosed, not hidden by permanently disabling SSL verification.

Postman has certificate settings for client certificates and certificate authority behavior. Do not confuse an API client certificate with the proxy’s basic authentication. They operate at different layers and should be documented separately.

• Check system date and time.
• Inspect the certificate subject, issuer and validity.
• Confirm the requested API hostname matches the certificate.
• Install only an approved organization CA.
• Retest direct and proxied paths to identify the failing layer.
• Remove temporary insecure settings after diagnosis.

Outbound proxy versus Postman capture proxy

Postman’s capture proxy listens on a local port so another client can send traffic through it for inspection. The official capture HTTP requests guide describes enabling a local proxy and starting a time-bound debug session. This does not configure Postman’s own outbound requests to use your purchased proxy.

When both are needed, draw the route first: client application to capture proxy, then onward according to the approved network configuration. Protect captured data because it may include cookies, tokens, request bodies and personal information. Limit the session and delete unnecessary evidence.

Troubleshoot Postman proxy problems

Use the Postman Console for request evidence, but redact secrets before sharing screenshots. The proxy error code guide distinguishes 407, 403, 429, gateway responses and timeouts.

A repeatable Postman regional API workflow

1. Duplicate the collection into an authorized test workspace.
2. Select the target environment and safe test data.
3. Configure one system or custom proxy mode.
4. Verify exit IP and location with a harmless request.
5. Send the API test and validate status, headers and response body.
6. Record timing, region, masked proxy ID and trace ID.
7. Keep retries bounded and respect target rate limits.
8. Remove temporary secrets, exports and captured traffic after the run.

For command-line reproduction, use the cURL proxy guide. For scripted JavaScript clients, continue with the Node.js proxy guide. Keeping the same endpoint and test contract across tools makes comparison easier.