What Burp Suite proxy problems usually mean
If you are trying to intercept traffic in Burp Suite and nothing appears in Proxy History, the issue is usually not the proxy itself but a configuration mismatch somewhere between Burp, your browser, and the operating system.
This guide explains how to fix Burp Suite proxy not working by isolating the most common causes and validating each layer in the request path.
Burp Suite, developed by PortSwigger, relies on a local proxy listener, a correctly configured client, and trusted TLS interception.
When one of those pieces is wrong, the result can be blank pages, connection errors, or traffic that bypasses Burp entirely.
Check that Burp Suite is actually listening
Start with the Burp Proxy listener because the browser cannot send traffic anywhere if Burp is not accepting connections.
In Burp Suite, open Proxy and then Proxy settings or Options, depending on the version.
- Confirm a listener exists on 127.0.0.1:8080 or another expected port.
- Verify the listener state is enabled.
- Make sure the binding address matches your setup, especially if you use a virtual machine, container, or remote browser.
- If another program is using the port, change Burp to an open port such as 8081 or 8888.
If Burp is configured to bind only to localhost, remote devices will not be able to connect.
For mobile testing or external browsers, you may need to bind to the machine’s LAN IP address or all interfaces, depending on your security policy.
Confirm the browser proxy settings
The most common reason people search for how to fix Burp Suite proxy not working is that the browser is still pointing at the wrong proxy.
Burp does not automatically control every browser unless you launch it through Burp’s embedded browser or configure the system/browser proxy manually.
What to verify in browser proxy settings
- HTTP proxy points to 127.0.0.1 and the same port as Burp’s listener.
- HTTPS traffic is also routed through the proxy, not only HTTP.
- No PAC file or enterprise policy is overriding the proxy.
- Firefox or Chrome is not using a separate profile with different settings.
In Firefox, the proxy settings are usually easier to manage manually.
In Chromium-based browsers, system proxy settings may be inherited, so you may need to update the operating system proxy configuration instead.
Use Burp’s built-in browser for a clean test
If your own browser has extensions, cached settings, or policy restrictions, test with Burp’s built-in browser.
This browser is preconfigured to use the proxy and is a reliable way to determine whether the issue is in Burp or in the client browser.
When the built-in browser works but your normal browser does not, the root cause is usually one of the following:
- Proxy settings are being overridden by an extension.
- Security software is intercepting traffic before Burp.
- Certificate trust is incomplete in the regular browser profile.
- Enterprise management policies block local proxy use.
Install the Burp CA certificate correctly
HTTPS interception depends on Burp’s CA certificate.
Without it, modern browsers will reject the connection or display certificate warnings that prevent the page from loading correctly.
To fix Burp Suite proxy not working for HTTPS, confirm that the Burp CA certificate has been imported into the browser or operating system trust store you are using.
Certificate trust checklist
- Download the CA certificate from http://burp while the browser is pointed at Burp.
- Import it into the browser’s trusted authorities or the OS trust store.
- Restart the browser after importing the certificate.
- Verify that HSTS sites and pinned certificate services may still fail even with a valid CA.
Some browsers, especially on macOS, Windows, and Linux, rely on the system certificate store.
Others maintain a separate trust store.
Make sure you install the certificate in the correct place for the browser you are using.
Disable features that bypass the proxy
Several browser and network features can silently bypass Burp Suite.
If traffic works for some sites but not others, look for settings that route requests outside the proxy path.
- Secure DNS / DNS over HTTPS can interfere with network behavior and troubleshooting.
- VPN clients may redirect or encrypt traffic before it reaches Burp.
- Corporate security agents can enforce direct connections or their own inspection proxy.
- Browser extensions may alter requests or open direct sockets.
Temporarily disable extensions such as ad blockers, privacy tools, and request-modifying extensions.
Also check whether a VPN, Zscaler, Cisco Umbrella, Netskope, or similar endpoint security product is installed, because these tools often change proxy behavior.
Check for loopback and localhost quirks
Burp commonly listens on 127.0.0.1, but some environments treat localhost, 127.0.0.1, and ::1 differently.
If the browser is configured for IPv6 localhost while Burp listens on IPv4 only, connections can fail.
To avoid this mismatch, try the following:
- Use 127.0.0.1 explicitly instead of localhost.
- Check whether Burp is listening on IPv6 if your browser prefers it.
- Review hosts file entries that may redirect localhost unexpectedly.
On some systems, browsers attempt IPv6 first.
If Burp is not bound to the IPv6 loopback address, the connection can appear broken even though the listener is active.
Test port conflicts and firewall rules
A local firewall or antivirus product can block Burp from accepting connections, especially after system updates.
If the listener is enabled and the browser is configured correctly but traffic still does not appear, verify that the selected port is open on the local machine.
Useful checks include:
- Confirm no other process is already using the proxy port.
- Allow Burp Suite through Windows Defender Firewall, macOS firewall, or Linux security tools.
- Review endpoint protection logs for blocked loopback traffic.
- Try a different proxy port to rule out application-level conflicts.
On Windows, tools like netstat can confirm whether something is bound to the expected port.
On macOS and Linux, lsof or ss can help identify conflicts quickly.
Validate HTTPS interception with a simple site
When troubleshooting how to fix Burp Suite proxy not working, use a simple HTTPS site before testing logins or complex web apps.
A site such as example.com or another low-risk page helps isolate basic proxy behavior without extra variables.
Check these signs:
- The request appears in Burp Proxy History.
- The browser shows a normal page load without certificate errors.
- You can toggle Intercept on and off and see requests pause as expected.
- Responses are visible in HTTP history for both HTTP and HTTPS traffic.
If HTTP works but HTTPS does not, the problem is almost always certificate trust, SNI handling, or security software interfering with TLS interception.
Use Burp’s logging and browser developer tools
Burp Suite and browser developer tools can narrow the issue quickly.
In Burp, review Proxy History and Event Log for warnings, certificate errors, or listener issues.
In the browser, open the network panel to see whether requests are leaving the client at all.
Helpful observations include:
- No network request in the browser means the client is blocking the connection before Burp.
- Requests in the browser but not in Burp point to a proxy routing issue.
- Requests in Burp with TLS errors suggest certificate or trust problems.
- Repeated connection resets may indicate AV, firewall, or VPN interference.
Special cases: mobile devices, VMs, and remote browsers
When you proxy traffic from an Android device, iPhone, virtual machine, or remote desktop session, the browser may need to point to the host machine’s LAN address instead of localhost.
In those cases, Burp must listen on an interface reachable from the client device.
Common adjustments include:
- Set the device proxy to the host IP address and Burp port.
- Ensure the host firewall allows inbound connections from the test device.
- Install the Burp CA certificate on the mobile device or guest OS.
- Confirm Wi-Fi and LAN segmentation are not blocking the route.
For Android testing, user-installed certificates may not be trusted by all apps on newer versions, especially when certificate pinning is present.
That is not a Burp proxy failure, but it can look like one.
Fast checklist to fix Burp Suite proxy not working
- Verify Burp Proxy listener is enabled and using the correct port.
- Confirm the browser or OS proxy points to the same address and port.
- Use Burp’s built-in browser to isolate browser-specific issues.
- Install and trust the Burp CA certificate for HTTPS interception.
- Disable VPNs, extensions, and security tools that bypass or intercept traffic.
- Check localhost, IPv4, and IPv6 binding behavior.
- Test for firewall or port conflicts on the local machine.
- Use a simple HTTPS target to validate basic interception.
By checking the listener, the client proxy settings, certificate trust, and network interception points in order, you can usually identify the exact reason Burp Suite is not capturing traffic without guessing.