Why DNAT to 127.0.0.1 Needs Special Care
Understand route_localnet when redirecting external traffic to a loopback-bound proxy component.
A service listens on 127.0.0.1:1080. A DNAT rule points incoming traffic at that address, yet the connection fails. The service can be healthy and the NAT rule can match: IPv4 loopback addresses have special routing treatment.
Linux's route_localnet controls whether 127/8 addresses are treated as martian addresses during routing. Its default preserves the usual loopback boundary. An interface-specific exception can be relevant to a deliberate local redirection design.
That explains why a working rule from another machine may depend on a sysctl you did not copy. It does not justify enabling the option everywhere.
The security assumption changes with the route
A loopback bind is often used because a helper has no independent client authentication. If traffic arriving from another interface can be routed to it, the bind address alone no longer describes the reachable audience. Restrict the ingress sources, destination and port in the actual ruleset, including traffic claiming loopback source or destination addresses where relevant.
Review the network namespace containing the service. A container's loopback is not the host's loopback, and changing a host-interface setting does not automatically create a listener in the container.
rp_filter answers a different question about source-path validation. Turning it off globally is not a general replacement for understanding loopback routing. Likewise, ip_nonlocal_bind concerns binding sockets to nonlocal addresses rather than making this DNAT path correct.
Finally, the redirected protocol must fit the listener. Sending raw HTTP or TLS traffic to a SOCKS port still needs a translator; a routing exception cannot supply the missing negotiation.