go-http-proxy-to-socks would listen in a specified netns and connect to another.

From here: 3proxy/3proxy#486

Please consider implement proxying between network namespaces. Despite broad 
info that process can only have sockets in one network namespace actually it can 
have opened sockets in multiple namespaces. All the opened sockets aren't affected 
by a setns system call. A socket is a network device with associated network namespace 
and new accepted connections are also belongs to the original socket namespace.

So the procedure is:

    Create a listen proxy socket

    Call setns() function and move the process into a new namespace

    Do chroot and other privilege deescalation stuff

    Do the main proxy loop as usual, accept connections on original socket 
and make new connections in the new network namespace

I don't know how to arrange this with a complex configs of multiple proxy 
interfaces but it is possible to make a simple proxy between namespaces 
this way without the performance overhead and setup pain associated with 
virtual veth interfaces between namespaces.

This Go package is useful for this implementation: https://github.com/vishvananda/netns

My intention is not to make spam here, but sing-box and GOST apps already implements it: https://github.com/SagerNet/sing-box - https://github.com/go-gost/gost

You can use this commit of sing-box as a basis: d2dc3ddf720f7946bc0773817ce81a228c49770c

What are the real-world use cases?

Suppose you have a LXC/Docker container and you want to set up a transparent proxy with DNS to it, so you just fire up go-http-proxy-to-socks with outgoing traffic pointing to host Internet (main netns) and listen ports of transparent proxies and DNS listening inside the netns of LXC/Docker. Setting up 2 go-http-proxy-to-socks'es, one listening on veth (virtual ethernet interface) of LXC/Docker and another inside the container is somewhat lame as will add overhead in the CPU and memory; but with netns support this can be done transparently.

There are some netns sanboxes for Tor, one example is Orjail. It works, but if go-http-proxy-to-socks would have netns support, one could just point go-http-proxy-to-socks to Tor and make the proxy and transparent proxy ports listen inside the netns of sandbox, thus not messing up with firewall rules, sysctl kernel values and the need of veth interfaces.

Network namespaces provide a greater level of network isolation rather than just setting up proxy rules on browser, one can just point sing-box to an external proxy and make sing-box listen inside the netns, so having the ability to use the Browser/app inside the network namespace with proxy with absolutely no IP leaks.

The options could be: --out-netns (where the upstream SOCKS5 server is reachable) and --in-netns (where the go-http-proxy-to-socks listen with its ports).