Postman Proxy Settings: Custom Proxy, Newman and 407 Fixes

Postman uses the word proxy for two unrelated features. The Proxy tab in the desktop app's settings decides how the requests you send leave your computer, and that outbound configuration routes API calls through Databay. The built-in capture proxy, started from Tools in the footer, listens on port 5559 by default and intercepts traffic from browsers, phones and other clients configured to use it. It is out of scope here, and Postman's capture guide does not describe forwarding captured traffic to an upstream proxy.

Databay provides one gateway, gw.databay.co on port 8888, for HTTP proxying, HTTPS CONNECT tunnelling and SOCKS5, with no UDP. The dashboard issues the username and password; the username also carries pool, country and session choices.

Use the route only for APIs you own or are permitted to test, and follow each destination's terms. A proxy changes a request's network path, not who is authorized to call an API.

Postman's Proxy settings page says Use system proxy and Respect HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables are on by default. With both Use system proxy and Use custom proxy configuration on, Postman uses the custom proxy. And Postman's proxy troubleshooting notes that when proxy environment variables are set, Postman uses the system proxy and ignores its own proxy settings, so an inherited variable is the first suspect when a check reports the wrong route.

Open settings from the gear icon in the header (Postman's pages call the item Settings or App settings), or press Ctrl+Comma (Cmd+Comma on macOS), then work under Proxy configurations for sending requests on the Proxy tab.

Copy the username exactly as the dashboard shows it. The documented example USER-zone-residential-countryCode-us requests a US residential exit; for other pools, copy the dashboard's string instead of editing this one. Proxy auth authenticates to the gateway; the request's Authorization tab authenticates to the destination API and is the wrong place for Databay credentials.

Postman's proxy guide lists HTTP, SOCKS5, SOCKS5H, SOCKS4 and SOCKS4A as proxy server types, and only HTTP and HTTPS requests can use a SOCKS proxy. SOCKS4 and SOCKS4A are not Databay protocols. Databay accepts SOCKS5 on the same port, but Postman documents Proxy auth as basic authentication without describing SOCKS5 username negotiation, so start with HTTP; HTTPS destinations keep end-to-end TLS inside a CONNECT tunnel. Try SOCKS5 only for a specific need, and keep it only if the same exit check passes; the HTTP versus SOCKS5 explainer covers the trade-offs.

The exclusion field at the end of the custom block takes a comma-separated list of hosts whose requests won't use the custom proxy. Limit it to local and internal hosts; an entry matching api.ipify.org or databay.com makes verification report your direct address.

1. With the custom proxy off, send GET https://api.ipify.org?format=json and save the returned ip in the active environment as directIp, the direct-route control.
2. Turn the custom proxy on and create GET https://databay.com/what-is-my-ip/json, which reports the observed address as UserIpAddress and a country estimate as IPCountry. Set the environment variable expectedCountry to the code you requested, such as US.
3. Add the script below under Scripts > Post-response and send.
4. Call the authorized API only after every test passes.

pm.test("endpoint answered", function () {
  pm.response.to.have.status(200);
});

const body = pm.response.json();

pm.test("exit differs from the direct control", function () {
  pm.expect(body.UserIpAddress).to.be.a("string");
  pm.expect(body.UserIpAddress).to.not.eql(pm.environment.get("directIp"));
});

pm.test("country matches the requested target", function () {
  pm.expect(body.IPCountry).to.eql(pm.environment.get("expectedCountry"));
});

Results appear on the Test Results tab. The Console, opened from Console in the footer, logs the proxy configuration and certificates used for each request; its network addresses are connection details, while the endpoint's answer is the observed exit.

A pass is point-in-time evidence that this request left through Databay, not proof of anonymity or future routing. Connection or tunnel reuse may keep the same exit, and a new connection may select another, but a different address is never promised. Record the Postman version, time, target and observed address; the What Is My IP page shows a sample response.

Newman needs its own route. Postman's Newman page names the Newman README as the full reference, and the README says Newman reads HTTP_PROXY/http_proxy, HTTPS_PROXY/https_proxy and NO_PROXY/no_proxy. These variables have no credential field, so this is the only place this guide shows the proxy URL form. Keep the whole URL in a masked CI secret, percent-encode reserved characters, never echo it or enable shell tracing around it, and use the separate fields in the desktop app.

# DATABAY_PROXY_URL: masked CI secret, form http://USER:PASS@gw.databay.co:8888
# Use http:// in both values; HTTPS destinations are tunnelled with CONNECT.
export HTTP_PROXY="$DATABAY_PROXY_URL"
export HTTPS_PROXY="$DATABAY_PROXY_URL"
export NO_PROXY="localhost,127.0.0.1"

newman run databay-exit-check.postman_collection.json \
  --env-var "directIp=$RUNNER_DIRECT_IP" \
  --env-var "expectedCountry=US" \
  --timeout-request 20000 \
  --bail

Export the exit-check request as that collection file, and capture RUNNER_DIRECT_IP from a run without proxy variables so an ignored variable fails the job. --timeout-request takes milliseconds; --bail exits with code 1 on a failed test. Never add -k or --insecure; the README documents --ssl-extra-ca-certs for a private CA. Postman now marks Newman as deprecated and recommends the Postman CLI; the CLI pages reviewed for this revision do not document proxy variables, so rerun the exit check before migrating a proxied job.

In the web app, Postman's install guide says you can configure a proxy for sending requests but not for connecting to online services. The selected agent decides where a request leaves from: the Desktop Agent uses your machine and network, the Cloud Agent Postman's cloud servers, the Browser Agent your browser, and the Interceptor Agent a browser extension. Run the exit check with the agent you will use.

Find the first layer that failed. The proxy hop is reaching gw.databay.co:8888, authenticating and opening a tunnel; the destination hop is TLS and HTTP with the API inside it. Classify the failed request's Console entry, since error wording varies by version.

Postman's troubleshooting pages suggest turning SSL certificate verification off when a certificate fails. Do not do that for real traffic, because Postman could then hand your API credentials to an intercepting device. Keep SSL certificate verification on in General settings and each request's Enable SSL certificate verification toggle on; for an internal API, the certificates guide documents adding its CA as a PEM file.

While verifying, set Request Timeout in General settings to a bounded example value such as 20000 ms, since 0 waits forever. To see whether time goes to the gateway or the API, repeat the request from a terminal with the cURL proxy guide, which separates connect, TLS and total timing.

Postman never chooses the Databay pool, geography or session; the dashboard-generated username does.

• Premium Residential: one of country, state, city, ZIP, coordinate or ASN targeting at a time.
• Residential Flex: country or continent.
• Datacenter and Mobile: country or continent.

Every Databay pool is shared; none reserves an address for one customer. A session segment, as in USER-zone-residential-countryCode-us-sessionId-abc123, requests continuity for up to 1440 minutes on Premium Residential and Residential Flex where available, or up to 120 minutes on Datacenter and Mobile. The IP can change before the window ends. Use it when a multi-step test against your own API should leave from one address, and re-run the exit check at checkpoints instead of assuming continuity held. Traffic is billed per GB, another reason to prefer the custom configuration: only the requests you route consume traffic.

• Keep the password in the team password manager or secret store; enter it only in Proxy auth or a masked CI secret.
• Never save proxy credentials in environments, collection variables, headers or the Authorization tab; those travel with exports and shared workspaces.
• Do not screenshot the Proxy tab with credentials visible, or paste settings into tickets and chat.
• The Console records proxy configuration and Postman's support guidance asks for Console logs, so redact usernames, passwords and authorization values first.
• After any accidental disclosure, replace the credential, then update the app and the CI secret.

Before the first real request, record the owner, approved API, product and session choice, and stop conditions: a 401, 403, 429, CAPTCHA or unclear permission ends the run until the owner resolves it.