An N2N Overlay Is Not a Proxy: Draw Both Connections

Firefox points at 127.0.0.1:8000, the N2N edge is up, the peer answers a ping on its overlay address, and the browser still reports that the proxy refused the connection. Nothing in that chain is contradictory. An overlay gives a host a reachable address on a private network; it does not create a process that speaks the proxy protocol. The browser is not asking for a route to a peer. It is asking for a local listener.

Two connections are being confused here, and drawing them separately clears up most of the confusion in a minute.

Two connections, not one

The first connection runs from the browser to whatever listens on the loopback port. That is a local socket, and if nothing owns it the connection is refused before a single packet reaches N2N. The second runs from the proxy process to the origin it is fetching. That path is chosen by the proxy host's routing table, and it may be the ordinary uplink, another tunnel, or a policy route that has nothing to do with the overlay.

Pinging the peer proves the overlay can deliver packets between edge addresses. It proves nothing about a listener on port 8000, and nothing about whether that host can reach the origin. Separate failures, separate fixes.

Where the listener has to live

A proxy bound to 127.0.0.1 is deliberately local: it accepts connections only from the machine where it runs. That is the right default for a personal proxy and the wrong shape for sharing one across an overlay. Serving overlay peers needs either a bind address on the overlay interface or a forwarding component that terminates the loopback connection and relays it. Either way, an explicit policy should decide which overlay sources may use the service, because an open proxy on a shared network is an invitation.

Check the actual bind with a socket listing rather than the configuration file. A daemon started before the overlay came up may still be bound to an address that no longer exists.

localhost is not the peer

In the browser's proxy field, localhost points at the browser's own machine. It is not the edge, not the supernode, and not the host at the far end of the tunnel. If the proxy runs on another peer, put that peer's reachable overlay address and port in the field, then confirm the listener accepts connections from your edge address.

Supernodes help edges find each other; they are not a proxy service. Treating a supernode address as a proxy endpoint produces the same refusal with an extra hop of confusion attached.

A route cannot perform a handshake

Even with the address right, routing is not proxying. An HTTP proxy connection begins with a CONNECT request or an absolute-form request line, and a SOCKS proxy begins with a version and method negotiation. A router or an overlay forwards bytes; it does not parse those messages or open the onward connection for you. That is why a route that works for ping and SSH can still fail for a browser proxy: the browser needs a cooperating process, not merely reachability.

If the goal is just to reach a service on the peer, remove the proxy setting and use the service's overlay address directly.

Test the boundaries in order

Confirm the overlay address answers, then confirm a listener exists on the configured port and note its bind address. Make one controlled request and read the proxy's log, so you know whether the failure sits at the listener or at the onward fetch. Finally, check the proxy host's route and DNS policy for the origin.

The N2N project documents edges and supernodes as overlay components. It does not turn an edge into an application proxy, and no routing configuration adds a protocol handler that nobody started.