The Proxy Server Is Refusing Connections in Firefox: Fix

The page you are looking at has this title and two suggestions, word for word from Firefox's own localization files (certError.ftl and netError.ftl in the Firefox source, read 2026-10-30):

The proxy server is refusing connections

  • Check the proxy settings to make sure that they are correct.
  • Contact your network administrator to make sure the proxy server is working.

Those suggestions are generic because the page is generic. In nsDocShell.cpp, Firefox routes five different internal errors to the same proxyConnectFailure page:

The first row hides the detail most guides miss. In nsHttpChannel.cpp, when a proxy asks for credentials and the authentication prompt is dismissed, Firefox cancels the load with NS_ERROR_PROXY_CONNECTION_REFUSED on purpose, so it never renders a proxy's 407 body as if the website sent it. So "refusing connections" can mean "the proxy is up and answering, it just wants a password or a whitelisted IP." That one fact reorders the whole diagnosis.

Firefox applies all of this to its own proxy settings, which are separate from the operating system's. If you have never confirmed which mode Firefox is in, our guide to configuring a proxy in Chrome and Firefox covers the dialog itself; this post assumes you already set a manual proxy and it broke.

Different misconfigurations produce different Firefox pages, and the title alone narrows the cause. We drove a Playwright Firefox 155 build with each bad configuration against gateway.sparkproxy.io on 2026-10-30, from an IP that was not on the whitelist, and recorded the error code Firefox returned. The page titles come from the same Firefox source mapping above.

Two things stand out. First, every SOCKS failure we produced landed on "Unable to connect", never on "refusing connections". If you see the refusing page, Firefox was talking to the proxy as an HTTP proxy. Second, a correct host and port with no authorization produces exactly the same page as a closed port. You can't tell those apart from the browser, which is why the next step tests the port from outside it.

One more result worth knowing: with only the HTTP Proxy field filled and Also use this proxy for HTTPS unticked, https:// sites loaded fine (direct, bypassing the proxy) while http:// sites threw the refusing page. If the error appears only on some sites, check that box before anything else.

Cheapest check first. Each step either fixes it or rules out a cause in under a minute.

1. Is an add-on in control? Open Settings, search for "proxy", and look for a banner saying an extension controls how Firefox connects to the internet. If one is there, your manual settings are not the ones in use. See Cause 1.
2. Is the right mode selected? In Connection Settings, confirm Manual proxy configuration is chosen, not "Use system proxy settings" (Firefox's default, network.proxy.type = 5).
3. Read the host and port back character by character. No scheme, no trailing slash, no spaces, and the port in its own box. See Cause 2.
4. Check which field holds the endpoint. An HTTP endpoint goes in HTTP Proxy with the HTTPS box ticked; a SOCKS5 endpoint goes in SOCKS Host with SOCKS v5 selected and the HTTP fields empty. See Cause 3.
5. Test the port outside Firefox. One curl command tells you whether the port is closed, open but asking for auth, or speaking the other protocol. See the next section.
6. Fix authorization. Add your current public IP to the whitelist, or supply credentials Firefox can actually send. See Cause 4.
7. Only then suspect the network. A corporate firewall, antivirus web shield, or VPN client that blocks outbound connections to non-standard ports will refuse the TCP connection too.

Firefox collapses several failures into one page. curl doesn't. These are real outputs from curl 8.21.0 on Windows, run on 2026-10-30 from a non-whitelisted IP:

# Closed or wrong port: TCP refused
curl -sS -x http://gateway.sparkproxy.io:11009 https://api.ipify.org
# curl: (7) Failed to connect to api.ipify.org:443 over proxy gateway.sparkproxy.io after 2945 ms: Could not connect to server

# Correct port, IP not whitelisted and no credentials: the proxy is up and wants auth
curl -sS -x http://gateway.sparkproxy.io:11000 https://api.ipify.org
# curl: (7) CONNECT tunnel failed, response 407

The second line is the important one. Firefox showed "refusing connections" for both, yet the second proxy is working perfectly. A 407 means fix authorization, not the port.

On Windows without curl, PowerShell answers the TCP half:

Test-NetConnection gateway.sparkproxy.io -Port 11000 | Select-Object RemotePort, TcpTestSucceeded
# RemotePort TcpTestSucceeded
#      11000             True

TcpTestSucceeded : False on port 11009 confirmed the refusal there.

To find out which protocol a port speaks, which is the question behind the SOCKS-vs-HTTP mix-up, this standard-library Python script sends the same handshakes Firefox would and labels each layer:

"""proxy_probe.py: test a proxy port the way Firefox uses it, one layer at a time."""
import base64
import socket
import sys

HOST = sys.argv[1] if len(sys.argv) > 1 else "gateway.sparkproxy.io"
PORT = int(sys.argv[2]) if len(sys.argv) > 2 else 11000
USER = sys.argv[3] if len(sys.argv) > 3 else ""
PASS = sys.argv[4] if len(sys.argv) > 4 else ""
TARGET = "sparkproxy.io"


def show(label, result):
    print(f"{label:<15} {result}")


def recv_or_empty(sock, size):
    try:
        return sock.recv(size)
    except (ConnectionResetError, socket.timeout):
        return b""


# 1. Can the proxy hostname be resolved?
try:
    ip = socket.gethostbyname(HOST)
    show("DNS", f"{HOST} -> {ip}")
except socket.gaierror as exc:
    show("DNS", f"FAILED ({exc}) -> Firefox: Unable to find the proxy server")
    sys.exit(1)

# 2. Does anything accept TCP on that port?
try:
    sock = socket.create_connection((ip, PORT), timeout=8)
    show("TCP", f"port {PORT} open")
except ConnectionRefusedError:
    show("TCP", "REFUSED -> Firefox: The proxy server is refusing connections")
    sys.exit(1)
except OSError as exc:
    show("TCP", f"FAILED ({exc})")
    sys.exit(1)

# 3. Does the port speak HTTP? Send the CONNECT Firefox sends for an HTTPS site.
req = f"CONNECT {TARGET}:443 HTTP/1.1\r\nHost: {TARGET}:443\r\n"
if USER:
    token = base64.b64encode(f"{USER}:{PASS}".encode()).decode()
    req += f"Proxy-Authorization: Basic {token}\r\n"
sock.sendall((req + "\r\n").encode())
reply = recv_or_empty(sock, 256)
sock.close()
if reply.startswith(b"HTTP/"):
    show("HTTP CONNECT", reply.split(b"\r\n", 1)[0].decode(errors="replace"))
else:
    show("HTTP CONNECT", "no HTTP reply (not an HTTP proxy port)")

# 4. Does the same port speak SOCKS5? Greeting = version 5, one method, no-auth.
sock = socket.create_connection((ip, PORT), timeout=8)
sock.sendall(b"\x05\x01\x00")
greet = recv_or_empty(sock, 2)
if greet[:1] != b"\x05":
    show("SOCKS5 hello", "no SOCKS5 reply (not a SOCKS5 port)")
else:
    show("SOCKS5 hello", f"SOCKS5 server, chose method {greet[1:2].hex()}")
    if greet == b"\x05\x00":
        name = TARGET.encode()
        sock.sendall(b"\x05\x01\x00\x03" + bytes([len(name)]) + name + (443).to_bytes(2, "big"))
        rep = recv_or_empty(sock, 2)
        show("SOCKS5 CONNECT", f"reply {rep[1:2].hex() or 'none'} (00 = allowed)")
sock.close()

Output from Python 3.14.2 against the real gateway, same day:

$ python proxy_probe.py gateway.sparkproxy.io 11000
DNS             gateway.sparkproxy.io -> 65.109.70.130
TCP             port 11000 open
HTTP CONNECT    HTTP/1.1 407 Proxy Authentication Required
SOCKS5 hello    no SOCKS5 reply (not a SOCKS5 port)

$ python proxy_probe.py gateway.sparkproxy.io 13000
DNS             gateway.sparkproxy.io -> 65.109.70.130
TCP             port 13000 open
HTTP CONNECT    no HTTP reply (not an HTTP proxy port)
SOCKS5 hello    SOCKS5 server, chose method 00
SOCKS5 CONNECT  reply 02 (00 = allowed)

$ python proxy_probe.py gateway.sparkproxy.io 11009
DNS             gateway.sparkproxy.io -> 65.109.70.130
TCP             REFUSED -> Firefox: The proxy server is refusing connections

Port 11000 is HTTP and wants auth. Port 13000 is SOCKS5 and refuses the target with reply 02, which RFC 1928 defines as "connection not allowed by ruleset"; from a non-whitelisted IP that is the whitelist talking. Port 11009 is simply closed. Pass a username and password as the third and fourth arguments to check credentials before you type them into the browser.

Firefox lets add-ons with the proxy permission decide routing themselves. MDN documents two routes: proxy.settings, which replaces the browser-wide configuration, and proxy.onRequest, which fires "when a web request is about to be made, giving the extension an opportunity to proxy it." When an add-on uses the first, Firefox's Settings page shows a banner (from preferences.ftl): "[Add-on name] controls how Firefox connects to the internet." The Connection Settings dialog also gains a Disable Extension button.

An add-on that routes through proxy.onRequest instead shows no banner at all, so the absence of one proves nothing.

That's the trap. You edit the manual fields, nothing changes, and the old broken proxy saved inside the extension keeps refusing.

Fix it one of two ways:

• Keep the extension, fix it there. FoxyProxy Standard 9.8 (released 2026-09-14 per its addons.mozilla.org listing, requires Firefox 128 or later) stores host, port, type and credentials per proxy. Open its options, correct the entry, and make sure the toolbar mode is the proxy you expect, not a pattern set that sends this site elsewhere.
• Take the extension out of the path. Switch FoxyProxy to "Off" or "Disable", or click Disable Extension in Connection Settings, then retest with your manual configuration.

A quick isolation test: open about:addons, disable every add-on that requests the proxy permission, reload the failing page. If the error changes or disappears, the add-on was the source.

SparkProxy hands out endpoints as host:port:user:pass. Pasting the whole string into the host box, or putting a URL scheme in front of the host, is an easy way to break it yourself. These are the fields and values for the gateway:

If you'd rather fix it in about:config or deploy it with a profile, these prefs are the same settings (names from Firefox's all.js and StaticPrefList.yaml). Put them in user.js inside the profile folder:

// user.js: manual HTTP proxy for HTTP and HTTPS through the SparkProxy gateway
user_pref("network.proxy.type", 1);                 // 1 = manual, 5 = system (default)
user_pref("network.proxy.http", "gateway.sparkproxy.io");
user_pref("network.proxy.http_port", 11000);
user_pref("network.proxy.ssl", "gateway.sparkproxy.io");
user_pref("network.proxy.ssl_port", 11000);
user_pref("network.proxy.socks", "");               // keep SOCKS empty for an HTTP endpoint

The port is the field that drifts. Gateways change, old blog posts publish stale ports, and a single digit off gives you a refused TCP connection. A one-off Test-NetConnection or the probe script settles it.

Firefox has separate boxes for HTTP and SOCKS, and each speaks a different first message. Put a SOCKS port in the HTTP box and Firefox sends an HTTP CONNECT to a server expecting a SOCKS greeting. In our test that produced "The connection was reset". Put an HTTP port in the SOCKS box and Firefox sends a SOCKS greeting to an HTTP proxy, which waits for a full request line that never comes; Firefox gave up after about 15 seconds with "Unable to connect".

When both the HTTP and SOCKS boxes are filled, you are guessing which one Firefox picks for a given request. Leave only one populated. For the protocol difference itself and SOCKS5 setup in code, see SOCKS5 proxy setup for Python, Node.js and browsers and SOCKS5 vs HTTP proxies.

SparkProxy supports two authorization methods: IP whitelist and username/password. Firefox handles them unevenly.

HTTP proxy, username and password. Firefox has no credential fields in Connection Settings. On the first request the proxy replies 407 and Firefox shows a login prompt. Enter the username and password and it works. Dismiss the prompt, or let a saved wrong password fail, and you get "The proxy server is refusing connections", because the cancel path maps to NS_ERROR_PROXY_CONNECTION_REFUSED as shown earlier. If the prompt never appears, check Connection Settings for Do not prompt for authentication if password is saved and clear stale saved logins for the proxy in about:logins.

SOCKS5, username and password. The manual dialog can't send SOCKS credentials at all. Our probe showed the gateway accepting the no-auth method and then refusing the target with reply 02 from a non-whitelisted IP. The MDN ProxyInfo reference documents username and password as "usable with socks", which means an add-on such as FoxyProxy can supply them. So for an authenticated SOCKS5 endpoint in Firefox, use FoxyProxy with the credentials filled in, or whitelist your IP.

IP whitelist. Add your current public IP to the whitelist in your SparkProxy dashboard, then retry. This is the cleanest fix for Firefox because nothing needs to authenticate per request. Watch three things: a home connection's public IP can change after a router restart; a VPN or corporate network gives you a different public IP than the one you whitelisted; and IPv6 vs IPv4 matters if your network prefers IPv6. More on the trade-off in what IP whitelisting is and how proxy authentication works.

The fast way to confirm this cause: if curl returns CONNECT tunnel failed, response 407, or the probe shows SOCKS reply 02, the port and protocol are right and only authorization is missing.

The Proxy DNS when using SOCKS v5 checkbox gets blamed for this error a lot. It controls where target hostnames are resolved, not whether Firefox can reach the proxy. Checked, Firefox sends the hostname to the SOCKS5 server and the exit resolves it (the SOCKS5h convention). Unchecked, Firefox resolves names locally and leaks them to your resolver.

In current Firefox source the checkbox maps to network.proxy.socks5_remote_dns, which defaults to true. The network.proxy.socks_remote_dns pref that many older guides name now sits behind the separate Proxy DNS when using SOCKS v4 checkbox and defaults to false, so flipping it does nothing for a v5 proxy.

Toggling it won't fix "refusing connections". In our tests the SOCKS v5 result was identical with socks5_remote_dns set to true and to false (NS_ERROR_CONNECTION_REFUSED both times), because the failure happened at the SOCKS handshake before any name was resolved. Keep it checked for privacy and geo accuracy, then look elsewhere. Leak testing is covered in our DNS leak testing guide.

A page loading is not proof. With "Also use this proxy for HTTPS" unticked, we watched an HTTPS site load straight past the proxy. Confirm the exit:

1. In the proxied Firefox window, open an IP echo endpoint such as https://api.ipify.org. The address shown should not be your home or office IP.
2. Run the same check from a terminal without the proxy to get your real IP for comparison.
3. Open DevTools (F12), Network tab, reload, click the request, and read Remote Address. Through a proxy, that's the proxy's IP and port (here, 65.109.70.130:11000), not the website's.

# Your real IP (no proxy)
curl -s https://api.ipify.org

# The exit IP through the same endpoint Firefox uses
curl -s -x http://USER:PASS@gateway.sparkproxy.io:11000 https://api.ipify.org

On Random Rotation (port 11000) the exit can change between connections, so two echo checks may disagree; that's expected. If you need one stable IP for a login flow, use Sticky Sessions on port 11002, which keeps the same exit for about five minutes. A longer verification checklist lives in how to test if your proxy is working.

Be clear about whose problem it is before opening a ticket.

Most rows are local. Switching providers won't fix a typo or a hijacking add-on. What a provider can do is answer quickly whether the port should be open and which auth method your plan uses. SparkProxy endpoints support HTTP/HTTPS and SOCKS5, with IP whitelist or user:pass auth, at 1 Gbps port speed across 1M+ premium IPs in 80+ countries. Plans start from $75/month (USD, read from the live pricing page on 2026-10-09) with unlimited bandwidth, and there's a 24-hour free trial with no credit card. Testing the exact Firefox setup above during the trial is a reasonable use of it.

If you only opened Firefox to check what a page returns through a proxy, consider skipping the browser. The SparkProxy Scraping API at https://scrape.sparkproxy.io/api/v1 takes your key in an X-API-Key header and fetches the page for you, so no local proxy config is involved:

curl -H "X-API-Key: YOUR_API_KEY" \
  "https://scrape.sparkproxy.io/api/v1?url=https://www.sparkproxy.io&render_js=false"

render_js defaults to true (5 credits); render_js=false is a plain fetch at 1 credit, and new accounts get 1,000 free credits.