[RFC] (Implemented) Per-App Transparent Proxy

[PeterFuApps]

Summary

Hi @ginuerzh @fernvenue ,

Proposal to add per-application transparent proxying via a new gost run subcommand. This routes traffic from specific applications through gost's proxy chain while leaving other system traffic unaffected.

gost run -F socks5://proxy:1080 -- firefox

I have already implemented this as a standalone Go wrapper with working Linux and Windows versions. If you're interested, I'd be happy to port it to gost v3 as a PR.

Why gost run Subcommand?

The existing -- separator in gost is used for multi-process spawning (cmd/gost/main.go:44-67):

# Existing: spawns two gost processes
gost -L socks5://:1111 -- -L rtcp://:3333/:1111 -F sshd://server:2222

A dedicated run subcommand avoids this conflict and provides cleaner semantics for per-app isolation.

Motivation

gost already has excellent TUN support for system-wide proxying. However, users often need to proxy only specific applications:

Use Case	Current Solution	Limitation
Proxy only browser	proxychains	Fails with static binaries (Linux)
Dev/test isolation	Docker + gost	Heavy, slow startup
Nested proxy chains	Not possible	TUN captures all traffic

Platform Support

Platform	Status	Implementation
Linux	✅ Implemented	User namespaces + TUN + gVisor netstack
Windows	✅ Implemented	WinDivert packet interception + gVisor netstack
macOS	❌ Not feasible	Network Extension API barriers

Why Not macOS?

Requirement	Issue
Apple Developer Account	$99/year recurring cost (required even for local builds)
App notarization	Must be signed by Apple
Language	Swift/Obj-C required; no pure Go

Proposed Usage

Basic

# Linux (no root required)
gost run -F socks5://proxy:1080 -- firefox

# Windows (administrator required)
gost run -F socks5://proxy:1080 -- firefox.exe

With Different Protocols

# Relay protocol
gost run -F relay://server:8080 -- curl https://example.com

# Tunnel protocol
gost run -F tunnel://server:8080?tunnel.id=my-id -- wget https://example.com

Proxy Chain

gost run --chain -F socks5://proxy1:1080 -F relay://proxy2:8421 -- curl https://example.com

Unix Socket

# Works on both Linux and Windows (Windows 10 1803+ supports AF_UNIX)
gost run -F socks5+unix:///path/to/socks5.sock -- curl https://example.com

Config File

gost run -C run-config.yaml

run-config.yaml:

forwards:
  - socks5://proxy1:1080
  - socks5://proxy2:1080

command: ["firefox", "--private-window"]
uid: 1000   # Linux only
gid: 1000   # Linux only

net: 192.168.123.1/24
mtu: 1350

Implementation

Linux: User Namespaces

┌─────────────────────────────────────────────────────────────────────┐
│  gost run -F socks5://proxy:1080 -- firefox                         │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  1. Parse command after "--"                                        │
│                                                                     │
│  2. Create child process with new namespaces:                       │
│     └── unshare(CLONE_NEWUSER | CLONE_NEWNET)                      │
│                                                                     │
│  3. Child creates TUN device inside namespace                       │
│     └── Has root capabilities inside user namespace                │
│                                                                     │
│  4. Pass TUN fd to parent via Unix socket pair                      │
│                                                                     │
│  5. Parent attaches TUN to gVisor netstack                          │
│     └── Forward TCP/UDP through chain                              │
│                                                                     │
│  6. Child sets TUN as default route, execs application              │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

No root required — user namespaces are unprivileged.

Windows: WinDivert

┌─────────────────────────────────────────────────────────────────────┐
│  gost run -F socks5://proxy:1080 -- firefox.exe                      │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  1. Parse command after "--", launch application                    │
│                                                                     │
│  2. Track launched PID and child process tree                       │
│                                                                     │
│  3. WinDivert intercepts outbound packets by PID                    │
│     └── If packet's PID matches → forward through chain            │
│     └── Else → re-inject directly                                  │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

Requires administrator privileges. WinDivert is an external DLL loaded at runtime (no CGO), same pattern as gost's existing Wintun dependency. Just ship WinDivert.dll + WinDivert64.sys alongside the binary. Both are pre-signed.

Integration with gost

Reuse Existing Components

Component	Reuse
gVisor netstack	Already used by TUN handler (Linux)
Chain forwarding	All connectors (socks5, relay, tunnel, http, etc.)
Config parsing	YAML/JSON support

Dependencies

Component	License	Platform	Notes
gVisor netstack	Apache 2.0	Both	Already in gost
WinDivert	LGPL	Windows	External DLL, same pattern as Wintun
divert-go	MIT	Windows	Go bindings, no CGO required for cross-compile

Nested Proxy Chains

gost run -F socks5://proxy1:1080 \
     -- gost run -F socks5://proxy2:1080 \
             -- firefox

Traffic: firefox → proxy2 → proxy1 → internet

How it works:

• Linux: Each nested gost runs in its own network namespace
• Windows: WinDivert priority system — inner gost uses higher priority, catches packets first, injects to outer gost

Unix Socket for Nested Mode (Linux)

TCP doesn't work across namespaces. Unix sockets can be bind-mounted:

gost run -F relay+unix:///tmp/gost.sock \
     -L relay+unix:///tmp/gost.sock \
     -- gost run -F relay+unix:///tmp/gost.sock \
             -- firefox

Use Cases

1. Selective routing — Proxy only specific applications
2. Development & testing — Route apps through different network paths
3. Nested chains — Hierarchical routing

Questions

1. Interest level? Would you be interested in per-app isolation via gost run?

2. Implementation scope?

   • Linux first, Windows follow-up
   • Both together

---

Looking forward to your feedback! Happy to submit a PR.

[fernvenue]

Yea I think this could be a useful feature, but I have two concerns personally. First, the complexity of this work means that maintenance down the road probably won’t be easy. Second, the proposal itself feels very AI-heavy. To be honest, that’s not really a good thing. I don’t have a problem with AI, but directly posting AI-generated content like this doesn’t feel appropriate. And yea, this is just my personal view and doesn’t represent any conclusion.

[PeterFuApps]

Yea I think this could be a useful feature, but I have two concerns personally. First, the complexity of this work means that maintenance down the road probably won’t be easy. Second, the proposal itself feels very AI-heavy. To be honest, that’s not really a good thing. I don’t have a problem with AI, but directly posting AI-generated content like this doesn’t feel appropriate. And yea, this is just my personal view and doesn’t represent any conclusion.

感谢反馈。

维护成本确实是个问题。Linux 的实现用的是和 Docker/Podman/runc 相同的内核机制（user namespace + network namespace），这套东西很成熟，维护负担不大。Windows 那边的 WinDivert 相对脆弱一些，不过也是外部 DLL 的模式，和 gost
现有的 Wintun 依赖一致。可以先只做 Linux，Windows 后续再看。

写法的问题我接受，下次会注意。

我从 v2 开始用 gost 很多年了，这次的功能也是基于实际使用中的需求。目前我已经有完整的实现，两个平台都跑通了。Linux 上嵌套能到 16 层，全程非特权运行，也支持动态 spawn——主要是为了解决嵌套场景下内外层网络需要独立路由的问题。目前是作为独立项目做的，协议层已经在用 gost 的库，合进来的话只需要加 namespace 这层，不引入额外的协议实现。

如果方向上有兴趣，我直接开个 Linux-only 的 draft PR，看代码更直观。

[alpominth]

@PeterFuApps

Here is a similar project: https://gitlab.torproject.org/tpo/core/oniux

There is also this netns port forwarder (socksns): https://github.com/stevenengler/socksns

You can also implement port forwarding and listening ports inside the cloned netns spawned by GOST, and also the ability to select the proper netns to be used.

[PeterFuApps]

@PeterFuApps

Here is a similar project: https://gitlab.torproject.org/tpo/core/oniux

There is also this netns port forwarder (socksns): https://github.com/stevenengler/socksns

You can also implement port forwarding and listening ports inside the cloned netns spawned by GOST, and also the ability to select the proper netns to be used.

@alpominth

Thanks for share two projects. Took a look at both. oniux is doing the same thing fundamentally — clone(2) + TUN + userspace netstack — but it's hardwired to Tor through arti/onionmasq so you can't use arbitrary proxy protocols. It also pulls in mount and PID namespaces for resolv.conf bind-mounting and process isolation, which I don't need since DNS resolution goes through the proxy chain directly. Still, nice to see the Tor project validating the same namespace approach.

socksns is a different beast entirely — it's not transparent. There's no TUN, no packet interception, no network stack. It just binds a TcpListener inside the namespace, passes the fd to the parent via Unix socket, and does copy_bidirectional. The app has to speak SOCKS itself.

One thing neither project supports is nesting. My implementation has a relay handler on a magic ip address inside the gVisor stack — inner gowrap instances auto-discover it and chain through the parent's proxy. So gost run -F proxy1 -- gost run -F proxy2 -- app just works, up to 16 levels deep. That's also how port forwarding inside the namespace works: you run gost with -L inside the nested namespace and it routes through the relay chain. Neither oniux nor socksns has a mechanism like this.

On port forwarding and listening inside the netns — do you mean something like docker run -p, exposing namespace ports to the host? Currently for nesting, the inner gowrap forwards to the parent's relay handler via a Unix socket (since TCP doesn't cross namespace boundaries but Unix sockets do, as the filesystem is shared). That already lets you run gost with -L inside the namespace and have it route through the relay chain.

If you have a specific CLI syntax in mind for that (like -p 8080:80 or reusing -L), I'd be interested to hear what you'd expect the command to look like.

On selecting an existing netns — socksns's --netns works for its use case because it only adds a listening port, doesn't touch routing. For a TUN-based approach like this, joining an existing namespace with its own routes would conflict. Nesting already covers that scenario cleanly: just run gowrap from inside the existing namespace and it creates a child namespace without touching the parent's network config.

[PeterFuApps]

[alpominth]

@PeterFuApps

On port forwarding and listening inside the netns — do you mean something like docker run -p, exposing namespace ports to the host? Currently for nesting, the inner gowrap forwards to the parent's relay handler via a Unix socket (since TCP doesn't cross namespace boundaries but Unix sockets do, as the filesystem is shared). That already lets you run gost with -L inside the namespace and have it route through the relay chain.

No, I mean spawning a listening port (like -L "socks5://127.0.0.1:1080") inside the cloned netns (there will be an active loopback interface inside the cloned netns.

Like this:

gost run -L socks5:://127.0.0.1:1081 -F socks5://127.0.0.1:1080 -- firefox --no-remote

/\ GOST will have the cloned netns default route pointing at the tun0 and additionally will listen in cloned netns loopback address at 127.0.0.1:1081.

[PeterFuApps]

@alpominth

I think there might be a misunderstanding about how this works. The cloned netns already has tun0 as the default route — all traffic from any app inside the namespace hits the TUN device and gets processed by the gVisor netstack, then forwarded through the proxy chain. The app doesn't need to know a proxy exists at all - this is what transparent proxy works.

So adding -L socks5://127.0.0.1:1081 inside the netns would mean: app sends to 127.0.0.1:1081, gost SOCKS handler receives it, connects to magic_ip, packet goes to tun0, netstack picks it up, forwards through the proxy chain. That's an extra hop for no reason — the app's traffic already goes through tun0 → netstack → proxy chain directly without any proxy configuration.

That's the whole point of doing TUN-based transparent proxying instead of what socksns does. socksns needs the app to speak SOCKS because it has no TUN, no netstack, no packet interception. Here the TUN catches everything.

Is there a specific use case you have in mind where the transparent TUN path doesn't work and you'd need an explicit SOCKS listener inside the namespace?

[alpominth]

Is there a specific use case you have in mind where the transparent TUN path doesn't work and you'd need an explicit SOCKS listener inside the namespace?

tunnel interfaces + Gvisor are pretty slow, having an proxy inside the namespace would be a workaround.

Here I get 2gbps with Gvisor, but with pure GOST Socks5 port I get 12 gbps on my AMD Ryzen 5 1400 CPU. Adding support for io.Copy in GOST would increase the speed to nearly 26gbps on my same CPU.

[PeterFuApps]

@alpominth
Gotcha, the netstack overhead is real. TUN path has to go through userspace TCP reassembly and TUN fd reads on every packet, so the throughput gap makes sense.

So TUN as catch-all to prevent leaks, plus an optional SOCKS listener on loopback for apps that support proxy config — bypasses netstack entirely. Makes sense as a design, I can factor that in.

Still waiting on maintainer feedback (@ginuerzh @fernvenue) on whether this is something they'd want in GOSTv3 though. If the direction gets a green light I'll include -L support in the netns mode.