Skip to contentBurp Suite can sit in the middle of your browser traffic, or it can send its own traffic through another proxy. Those are not the same thing. If you mix them up, you can spend 20 minutes staring at the wrong screen.
This guide focuses on one job: how to set up a proxy in Burp Suite without confusing the local intercepting proxy with the outbound path. In plain terms, your browser talks to Burp on one port, and Burp may then talk to a second proxy before it reaches the target site. That second hop is where the burp suite upstream proxy comes in.
If you want background on proxy terms, the VPN and proxy glossary is a useful side tab. If your broader workflow includes automation, the how to choose a VPN article helps with the network side. Not every setup needs both.
1. Decide Which Burp Proxy Scenario You Actually Need
Start with the traffic path. Scenario one: browser to Burp, then Burp to the site. Scenario two: browser to Burp, then Burp to another proxy, then out to the site. The second one is the one people usually mean when they ask for how to set up a proxy in Burp Suite, but the first one is what Burp does by default.
One quick test helps. If your goal is to inspect requests from Chrome or Firefox, you need Burp as the local intercepting proxy. If your goal is to make Burp itself exit through a corporate relay, a home SOCKS server, or a privacy gateway, you need an upstream proxy. That difference matters because Burp’s listener settings do not control outbound chaining.
One is local. One is upstream.
Burp is often used in labs, office networks, and QA environments where the browser can reach Burp directly but Burp cannot reach the target host directly. A common example is a remote test box on a restricted network where Burp must go through a company proxy on port 8080 or 3128. Another example is a research machine that needs outbound authentication before any HTTP request is allowed.
2. Find the Right Place in Burp Suite Proxy Settings
Open Burp Suite and look for the Proxy area first, not the browser controls. The relevant items usually live under the Proxy tool, the settings panel, and the listener and upstream sections. If you only click around in the intercept tab, you will miss the place where routing actually changes.
There are two different kinds of settings to check. The listener controls what address and port Burp listens on for incoming browser traffic. The upstream controls determine where Burp sends traffic after it has already received it. Those are separate fields for a reason.
Look for the parts of the interface that mention listeners, proxy listeners, and request handling. Then find the area tied to burp suite proxy settings. The exact menu names can vary by Burp release, so the safe method is to search for the proxy listener and upstream proxy controls, not for a single screenshot from an old guide.
Small note: Burp does not care what browser you use here. It cares about the host, the port, and whether the listener is running.
3. Configure Burp as Your Local Intercepting Proxy
For the browser-to-Burp link, use the loopback address if the browser is on the same machine. That usually means 127.0.0.1 with a port such as 8080. The browser must point to the same host and port that Burp is listening on, or the requests never arrive.
Set one listener. Then check it. Then check it again.
In practice, the browser proxy settings should match Burp exactly: same IP, same port, same protocol expectations. If Burp is listening on HTTP on 127.0.0.1:8080 and the browser points to 127.0.0.1:8081, nothing works except confusion. If a firewall blocks the chosen port, Burp may still look ready while the browser connection fails immediately.
Use the browser only as the client in this step. Do not try to solve outbound proxying yet. People often change three settings at once, then lose track of the one that broke traffic. Keep the job narrow: make sure Burp can receive traffic first.
If you are comparing proxy types for a later chain, the SOCKS5 proxy vs HTTP proxy guide is worth a read. Burp can sit in front of either style, but the upstream proxy fields need the right kind of server details.
4. Set an Upstream Proxy in Burp Suite
This is the part most readers want. The burp suite upstream proxy tells Burp where to send outbound requests after it has intercepted them. It is the right choice if your traffic must pass through another HTTP proxy, a SOCKS relay, or a corporate gateway before reaching the destination.
Enter the upstream proxy host and port carefully. A typo here creates a dead end, not a warning. If the upstream proxy requires authentication, Burp may need a username and password, and some environments also expect specific transport rules or proxy headers. That depends on the proxy service you are using.
Use upstream routing when Burp should keep its local listening role but still forward requests elsewhere. Use it for controlled egress, for lab networks, or for testing how a target behaves from a specific outbound path. If you only need to inspect browser requests locally, you do not need upstream routing at all.
One useful case is a test workstation that must reach the internet only through a managed proxy. Another is a debugging session where the target site should see a particular exit path, while Burp still records and edits the request in the middle. That middle step is the whole point.
If your upstream is authenticated, this older guide on the authenticated SOCKS5 proxy can help you sanity-check the credential format. It is easy to get the host right and the login wrong.
5. Adjust Burp Suite Proxy Settings for Match-and-Route Rules
This is where burp suite proxy settings stop being a single toggle and start behaving like a routing system. Burp can match requests by destination, scope, or other request properties, then decide whether to send traffic, intercept it, or pass it on. If your traffic seems to ignore the proxy chain, the rule set is often the reason.
Check the scope first. If Burp is set to only handle in-scope items, traffic outside that scope may bypass the path you expect. Check any match-and-route rules next. A rule for one domain can send traffic one way while another rule sends it somewhere else, which is fine until you forget you created the rule three days ago.
Keep the logic simple. One listener. One upstream proxy. One test target. If you need more complex behavior later, build it one rule at a time. That way you can see which setting changed the result.
The proxy chain can also be affected by handling decisions in Burp’s intercept and forwarding behavior. If requests appear in history but never reach the server, look at whether they are still paused for interception. If they leave Burp but never return, the route or the upstream proxy may be wrong.
For a quick reference on routing concepts, the proxy rotation for web scraping guide explains how request flow changes when proxies are swapped. Different use case, same habit: know which rule is sending traffic where.
6. Test the Proxy Chain End to End
Test in three steps. First, confirm the browser can reach Burp. Second, confirm Burp can reach the upstream proxy. Third, confirm the upstream proxy can reach the target site. If any step fails, the chain breaks there.
Start with Burp’s proxy history. Send one request from the browser and watch whether it appears. If it does not appear, your browser-to-Burp setup is wrong. If it appears but stalls, intercept may still be holding it. If it appears and leaves, but the target never responds, the upstream path is the likely problem.
Then use a known test page or a simple destination that returns visible headers. You want a response that proves the request traveled through the whole chain, not just that Burp displayed something. A request that returns a 200 response from the target through the upstream proxy is a better signal than a generic “connected” message.
One good habit is to compare source IP and observed routing with a separate check. The article on how to verify your IP is hidden can help you confirm what the outside world sees. That is especially useful when the upstream proxy is part of a privacy or corporate setup.
7. Fix the Most Common Burp Proxy Misconfigurations
Wrong listener address is the first failure. Burp listens on 127.0.0.1, but the browser points to a different host. Or Burp listens on a specific interface, but the browser tries another one. Either way, the request never reaches Burp.
Port conflict is next. If another app already owns the port, Burp may not bind to it cleanly. The symptom is often a browser timeout, not a neat error message. Change the port, restart Burp, and test again.
Upstream authentication is another common snag. One missing password, one expired token, or one wrong auth scheme is enough to break the chain. If your proxy provider uses credentials, check them against the proxy authentication best practices guide before assuming Burp is broken.
SSL/TLS interception can also fail if the browser or the target does not trust the Burp CA certificate, or if the upstream proxy rejects CONNECT requests. That can look like a certificate error in the browser, a connection reset in Burp, or a blank response from the site. In practice, you diagnose it by watching which hop dies first.
Traffic not matching Burp rules is the last frequent problem. If a host is out of scope, excluded by a filter, or sent by a browser extension around the proxy, Burp may never see it. Check the browser extensions too. One can bypass the whole chain without warning.
If you need a broader background on proxy and privacy setup, the VPN, proxy & privacy guides page collects related material in one place. It is a sensible next stop if your Burp setup is part of a bigger testing environment.
8. Save a Reusable Burp Configuration for This Workflow
Once the chain works, save it. A working Burp profile is worth keeping because the same listener, scope, and upstream settings often return in the next project. Rebuilding them from scratch is wasteful, and it invites tiny mistakes in the port or host fields.
Export the configuration if your Burp version supports it. If export is not available in your edition, keep a short note with the listener address, port, upstream host, upstream port, and any authentication details you need to re-enter later. Five lines are enough. Ten is better if credentials are handled outside the file.
One practical trick: store the setup name with the project name, such as “lab-chain-01” or “client-proxy-02.” That makes it easy to reload the same Burp proxy settings on the next machine. It also helps when you switch between test environments with different upstream proxies and different auth requirements.
Keep the saved profile tied to one purpose. A Burp setup for browser inspection should not be reused blindly for a corporate upstream proxy, and a profile built for SOCKS access should not be assumed to work on HTTP without rechecking the host, port, and authentication fields. Those three values decide whether traffic moves at all.
Save the profile now, while the chain still works.