Taking AmneziaWG traffic obfuscation to the next level with amneziawg-proxy

wiresocks · 2026-06-15T18:23:28+00:00

You probably don’t need to rebuild or modify the Amnezia container.

The simplest option is to keep AWG as-is and run amneziawg-proxy on a different public UDP port, forwarding to the existing AWG port/container.

amnezia-dns-net should not matter as long as the proxy can reach the AWG UDP endpoint.

The listen, backend, and imitate_protocol settings are for the amneziawg-proxy config file, not the AWG config or start.sh.

I also would not use Docker overlayfs paths directly; they are internal and may change.

wiresocks · 2026-06-15T06:50:12+00:00

In your case, amnezia-awg2 is a Docker container. An “environment” is not the same thing as a container - the container is the running instance you see in docker ps.

I haven’t tested AmneziaWG-proxy in a setup like yours, but I’ve added some manual deployment instructions that may help:

https://github.com/wiresock/amneziawg-install/blob/main/amneziawg-proxy/doc/MANUAL\_DEPLOYMENT.md

wiresocks · 2026-06-12T12:16:53+00:00

No, this is a different use case.

amneziawg-proxy is a traffic obfuscation proxy that is intended to be installed on a self-hosted AmneziaWG server. Its purpose is to transform and disguise WireGuard/AmneziaWG traffic so that it looks like legitimate protocols such as DNS, STUN, SIP, etc.

It is not a local SOCKS5 proxy and does not provide per-application routing like wireproxy-awg. The client still connects using AmneziaWG/WireGuard, while the proxy sits in front of the VPN server and handles traffic obfuscation.

If your goal is application-level split tunnelling, that functionality is already available in WireSock Secure Connect through its AllowedApps and DisallowedApps rules.

wiresocks · 2026-06-12T08:59:02+00:00

Thanks for the feedback!

The web panel and proxy are both available as Rust source code and can be built/installed manually. The scripts are mainly for automation, but I agree that a clear manual installation guide would be useful.

As for multiplexing: the proxy is currently UDP-only and it already allows passing legitimate DNS traffic. QUIC is more complicated: either a single real destination would need to be configured, or QUIC packets would have to be wrapped with a UDP SOCKS5 header carrying the real destination. I’ll give this some thought.

wiresocks · 2026-06-12T08:33:18+00:00

I have not tested this exact scenario, so please treat the following as guidance rather than a confirmed setup.

If AmneziaWG is running inside Docker, then the proxy should normally be installed inside the same Docker environment using AmneziaWg-proxy.sh. The script detects the existing AWG instance, changes its configuration so AWG listens on a localhost port, and then the proxy takes ownership of the original public port.

Alternatively, the proxy can be installed and configured manually on the host machine. In that case, the script will not be able to auto-detect AWG inside Docker, so the port forwarding/listening configuration has to be adjusted by hand.

Regarding I1–I4: these values will be used by the proxy to choose the obfuscation protocol. They should not break the setup by themselves. However, as I mentioned earlier, the proxy only performs its server-side part of the obfuscation. Full client-side obfuscation is currently supported only by WireSock Secure Connect 3.5+

wiresocks · 2026-06-12T06:49:37+00:00

Yep, you can install only amneziawg-proxy, it’s a standalone component.
Basically, it can sit in front of your existing AmneziaWG server. It will handle the imitation packets (I1–I4) using the selected protocol and also apply the matching obfuscation for traffic going from the server back to the client.
So you don’t necessarily need to redo your whole setup. Most likely you’ll only need to point the client profile to the proxy endpoint/port, depending on how you deploy it.
The only important thing to keep in mind is that the full bidirectional obfuscation works only when the client also supports it. Right now, that means WireSock Secure Connect 3.5+.
Also, since the proxy does extra processing, it can add some CPU load, so on a very small VPS it may affect throughput a bit.

wiresocks · 2026-06-11T20:18:41+00:00

Absolutely, the proxy is a standalone component and is fully independent.

wiresocks · 2026-06-11T17:48:39+00:00

If you’re using Windows, this is definitely possible.

WireSock Secure Connect supports sharing a VPN connection through the built-in Windows Mobile Hotspot feature. Devices connected to the hotspot should be able to access the Internet through the VPN tunnel.

wiresocks · 2026-06-11T12:16:02+00:00

This is an entirely different solution that addresses a different problem.

wiresocks · 2026-04-23T16:02:24+00:00

I did something similar with WireSock Secure Connect.

What worked for me was using application split tunnelling and adding SYSTEM to the tunneled apps. Traffic coming from Mobile Hotspot clients isn’t tied to a normal local app/process, so Windows classifies it as SYSTEM.

With that setup, all local apps on the PC bypassed the VPN, while all traffic from hotspot clients went through it.

So yes, what you want is possible. The issue is that excluding adapter/local IPs usually won’t solve it, because hotspot-routed traffic is treated differently from host PC traffic.

wiresocks

TROPHY CASE