Burp Suite upstream proxy setup: route Burp through a proxy for authorised testing

Burp Suite is a web-security testing tool whose own proxy sits between a browser and the sites you are authorised to test. To make Burp's outbound traffic leave from a proxy IP as well, add a rule under Upstream proxy servers: open Settings, go to Network then Connections, and add a rule with * as the destination host, your proxy's host and port, authentication type Basic, and the username and password from your order. Use this only against targets you have written permission to test, which is the one security use ProxyHive's allowed-use policy permits.

Burp is a GUI application we could not run on our test machines, so the setting names below follow PortSwigger's own documentation.

#Before you start

1. Confirm you have written authorisation for every in-scope host. The policy reserves penetration testing and vulnerability research to systems you own or are contracted to test, and we may ask to see that permission.
2. Open your order in the dashboard at https://app.proxyhive.io and copy HOST, PORT, USERNAME and PASSWORD.
3. Check the proxy works on its own: curl -x http://USERNAME:PASSWORD@HOST:PORT https://api.ipify.org. If that fails, Burp will too; the curl guide has the flags.

#Upstream proxy servers

PortSwigger's docs describe the flow: "Burp evaluates the rules in order and uses the first rule in the table that matches the destination host," and "If no rule matches the destination host, Burp connects directly to it." To send everything through one proxy, the docs say to "create a rule with * as the destination host."

In Settings > Network > Connections, under Upstream proxy servers, add a rule:

With Basic chosen, Burp fills the username and password fields. The domain, domain hostname and SPNEGO fields appear only for NTLM, which a proxy dashboard login does not use. Narrow the destination host to your scope so unrelated traffic, such as PortSwigger's own update checks, does not run up proxy usage.

#SOCKS proxy

To route every connection at the TCP level instead, use Use SOCKS proxy on the same page:

• SOCKS proxy host and SOCKS proxy port from your order's SOCKS5 port.
• Username and Password, if your order authenticates that way rather than by IP allowlist.
• Do DNS lookups over SOCKS proxy resolves names at the proxy; the docs note "When enabled, Burp does not perform any local DNS lookups," which keeps target names off your own resolver, the same idea as socks5h.

One interaction to know: the docs say "every outbound connection, including requests to upstream HTTP proxies, goes through the SOCKS proxy." So a SOCKS proxy and an upstream HTTP proxy are not either/or; the SOCKS layer wraps the HTTP one. Pick one path unless you deliberately want both.

#Burp's own certificate

Burp's embedded browser trusts Burp's CA already. For an external browser or tool, download Burp's CA by visiting http://burp (or the proxy listener's address, http://127.0.0.1:8080 in the docs' example) and trust it. That is Burp decrypting the traffic you are inspecting; it is separate from the upstream proxy, which only forwards Burp's connections onward.

#Check the exit IP

Point a browser at Burp, then open https://api.ipify.org?format=json. The ip should be your proxy's, and Burp's HTTP history should show the request. If it is your own IP, no upstream rule matched the host; widen the destination host or check the wildcard. A 407 in Burp's response means the proxy rejected the credentials, which the proxy error codes guide covers.

#With ProxyHive

An authorised test that must come from one declared, stable address is what a datacenter IP gives you: a static exit in the country you choose at checkout, which the target's owner can allowlist for the engagement, with HTTP, HTTPS and SOCKS5 and username and password authentication. For the open-source scanner with the same upstream-proxy setup, see OWASP ZAP.