Short answers
Where do I configure a proxy in Postman?
Open Settings, then Proxy, and choose a custom proxy for sending requests. Enter the gateway hostname and port in their separate fields. The instructions below use the desktop app.
Does my API request need Basic Auth for the proxy?
No. Enter the gateway credentials in the proxy authentication settings. The request’s Authorization tab belongs to the destination API and may contain a different credential or no credential at all.
Is this the same as Postman’s built-in capture proxy?
No. Request routing sends your Postman request through an external gateway. The capture feature receives traffic from another client for inspection. You do not need to start a capture session to use the setup below.
Separate the request from the network route
Use a small GET request to the echo endpoint first. Keep your production API collection closed while changing global routing settings: its authentication, scripts and saved request bodies are unnecessary for this check. Record the app version and the original proxy settings so you can restore the configuration after testing.
Copy the complete generated proxy username from the connection builder, selecting a currently available pool and country. Keep the gateway password ready. Your account password and API key do not replace that password. The hostname and ports shown below come from the same gateway configuration used by the site’s documentation.
Configure a custom proxy
In the desktop app, open Settings → Proxy and enable the custom configuration for requests. Choose HTTP, apply it to HTTPS requests, and enter the separate fields below. Enable proxy authentication. Postman’s proxy configuration reference describes the controls; their labels may vary by app version.
| Field | Value |
|---|---|
| Proxy server hostname | gw.portproof.org |
| Port | 7000 |
| Proxy username | The complete generated username from your dashboard |
| Proxy password | Your gateway password, entered in the proxy settings |
| Destination URL | https://api.portproof.org/v1/echo-ip |
Enter only the hostname in the host field, without a scheme, path or credentials. Ensure the echo destination is not excluded from proxy routing. For a deliberate custom route, review the system-proxy and environment-variable options too. Postman documents those controls in its Proxy settings.
Send one request and inspect the result
- Create a new GET request with https://api.portproof.org/v1/echo-ip as the destination URL.
- Choose No Auth for this echo request. Remove inherited API authentication and manually added authentication headers.
- Keep certificate verification enabled. Set a finite request timeout before sending.
- Send once, then inspect the response status and JSON body together. The expected echo response includes an ip field.
- Record the time, chosen pool, requested country, session mode and observed address without saving passwords or authentication headers.
A returned address describes the route taken by that request. It does not prove a country, a particular carrier or a later request’s outcome. If you require regional QA, verify the actual application result as well as the address and record how the destination determines location. The country-check guide explains common differences.
In Settings → General, Request Timeout is measured in milliseconds; zero leaves the wait unbounded. Max response size is a separate setting. Choose a finite value appropriate to this small diagnostic response and leave SSL certificate verification enabled. See Postman’s general settings reference.
Keep the two authentication steps apart
For an HTTPS destination through an HTTP gateway, the gateway first handles CONNECT. The destination TLS exchange follows inside that tunnel. A rejected CONNECT can stop the request before the API receives anything, so changing the API token cannot repair a gateway-password error.
Do not manually add Proxy-Authorization to a collection’s ordinary request headers. Do not put the gateway password into the destination URL. These choices can send a secret to the wrong recipient or save it in request history. Treat screenshots, console output, exported collections and support attachments as material to review before sharing.
Use the failed stage to choose the next check
| Observed result | Next check |
|---|---|
| 407 or a CONNECT authentication failure | Recheck the complete proxy username, proxy password, host and port. Use the 407 guide before editing API credentials. |
| Certificate validation failure | Inspect the destination hostname, system clock and approved certificate chain. Keep verification enabled. |
| Timeout before a response | Compare with one bounded curl check from the same machine. Check network access and routing configuration before increasing the timeout. |
| 403 or 429 from the destination | Follow that service’s access rules or request-rate policy. Record the response source and stop uncontrolled retries. |
| Echo works but the API request fails | Check the API URL, method, credentials, payload and expected response separately from the gateway. |
The curl check gives you a second client on the same machine. A passing curl command does not transfer its settings into Postman. Compare configuration explicitly, then follow 407 troubleshooting, connection refused and timeouts or the environment-settings guide for the failed stage.
Move from the check to a real workflow
Once the echo works, send one authorised read from your collection and validate its contents. Then try a small representative sequence. An HTTP 200 containing the wrong account, region or empty data is not a useful result. Avoid replaying purchases, submissions or other actions merely to test connectivity.
A collection’s cookies and variables describe application state; gateway rotation is a separate setting in the proxy username. Repeated sends may reuse connections, and a sticky session can retain the device while its IP changes. Keep one intended configuration throughout related steps. See rotation and sticky sessions.
Count attempts and useful responses, and compare traffic in your dashboard before expanding the workload. Account for meter updates and other jobs sharing the balance. The bandwidth guide helps estimate a larger run; pricing supplies the current order terms.
Desktop configuration and evidence
These instructions were checked against Postman’s official documentation on 1 October 2026. They are a desktop configuration walkthrough, not a live-pool benchmark or a recorded Postman application test. A web client, agent, CLI or hosted runner is a different execution environment: verify its proxy support and route separately before assuming it inherits desktop settings.
Postman’s capture proxy documentation describes a separate inspection workflow that can install a local certificate. Leave that feature out of this outbound-routing check. After testing, restore the intended desktop configuration before sending unrelated collections.
What is not allowed
Use the proxy for authorised API testing, monitoring and research that respects the destination’s terms and the acceptable-use policy.