Tinyproxy Listen, Bind and BindSame: Which Address Wins
Listen picks the address that accepts clients, Bind picks the source for outgoing ones. Neither installs a route, so verify the path on its own.
The proxy answers, the request completes, and the destination still records the LAN address. Nothing in the proxy log looks wrong, and the line you changed is the one the documentation told you to change. On a host with both a LAN address and a tunnel address, three directives decide which address appears where, and only one of them is about the outgoing side. Reading them in the wrong order sends you into the routing table for no reason.
The symptom: the destination sees the LAN address
A client connects to the proxy on the LAN address, and the proxy opens its own connection to the destination. That second connection picks a source address by the kernel's rules, and by default it is whatever the route lookup selects. The destination therefore records the host's primary address even though every byte passed through the proxy. Nothing is broken in the forwarding sense, which is why the proxy log has nothing to say about it.
The mirror image of that fault is easier to spot: pin the outgoing source to the tunnel address and LAN clients stop reaching the listener altogether. That version announces itself, while the first one hides behind a working request. Both come from treating one directive as if it answered both questions.
Three directives, three different addresses
Listen names the local address that accepts proxy clients. Bind supplies a source address for the connections the proxy makes outward, and BindSame tells it to reuse the local address of the connection it just accepted. Those are three separate questions, and a single line answers only one of them. Mixing them up is the usual reason a change appears to do nothing.
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
Read the annotated configuration shipped with the installed version, because defaults and accepted syntax move between releases. The project's sample configuration documents each directive beside the others. Compare that file with the one on disk, not with a guide written for a different distribution.
Set the listener and the outgoing source independently
Take a host whose LAN address is 192.168.50.10 and whose tunnel address is 10.90.0.3. If LAN clients should reach the proxy while their requests leave from the tunnel, those are two independent decisions and both have to be written down. The fragment below expresses exactly that and nothing else.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noIt is not a complete configuration, so keep the approved port, the authentication, the client access controls and the destination restrictions. Both addresses have to belong to this host inside Tinyproxy's network namespace, because a Bind value the process cannot own fails at connect time rather than at startup. BindSame yes describes a different policy, where the accepted connection's local address becomes the outgoing source. In current releases that branch takes precedence over the Bind list, which is how a configured source disappears without an error.
Check the route that the source implies
Choosing a source address does not create a path, so ask the kernel what it would do with that source and that destination. A lookup that names the tunnel interface is the minimum evidence, and one that names the LAN interface means the source cannot work as written. The lookup is contextual: it evaluates the policy rules and the table in force for that namespace. It is not a connection, and it says nothing about what a downstream NAT will present to the service.
ip -4 route get 203.0.113.25 from 10.90.0.3Use a documentation address in the example and substitute the service you are authorized to test. Run the lookup inside the proxy's namespace when the proxy is containerised, since the host's rules are not the rules the process sees. When the intended tunnel route is absent, have the network owner fix it rather than adding destination-specific rules to the proxy host. Do not flush host routes or disable server-pushed routes to make a lookup succeed, even if an older guide did, because those changes move the whole host's approved VPN behavior to repair one proxy path.
Confirm the source at the destination
Read the source where the request arrives, not where it leaves. The destination's application log, or the edge device in front of it, records the address it actually saw, while the proxy can only tell you what it intended. Make one fresh request through the intended listener after the change, because a cached connection proves nothing about the new binding. Then compare that recorded address with the one you configured.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sSThe curl is only the traffic generator; the address worth verifying is the one the far side logged, not the peer curl happened to connect to. If the two disagree, decide whether the difference comes from source selection or from translation further along, because those are fixed in different places. Plan address changes and proxy restarts together as well, since binding an address the tunnel no longer holds fails quietly after a reconnect. Define DNS and IPv6 behavior separately too, because the IPv4 fragment above proves nothing about either.