Wireproxy is an open-source Go application that connects to a WireGuard peer and exposes the connection as a SOCKS5 or HTTP proxy. Unlike a standard WireGuard client — which creates a new network interface and needs root or administrator privileges — wireproxy runs entirely in userspace. You keep WireGuard’s encryption without touching your system’s network stack.

The project sits at 5,700+ stars on GitHub, maintained by windtf under the ISC license. It ships as a single static binary for Linux, macOS, and Windows.

The value proposition is straightforward: instead of routing every bit of your traffic through WireGuard, you pick which applications enter the tunnel by directing them at a local proxy.

Why Use WireGuard as a Proxy Instead of a Full VPN?

A full VPN routes everything. That covers your needs when you want blanket protection — but it also introduces problems that never quite go away:

• Split tunneling is unreliable. Most VPN apps include an option to exclude specific apps or IP ranges, but implementations differ wildly across platforms. On Linux, split tunneling often boils down to manually written routing tables that break after system updates.
• Root access isn’t always available. University computer labs, corporate laptops with locked-down policies, CI/CD runners — you can’t just run sudo wg-quick up on these machines.
• VPN conflicts happen. Running two VPNs at once? The second tunnel typically fails because the first already owns the routing table. Wireproxy sidesteps this: your primary VPN stays active while a second WireGuard connection operates as a proxy that only specific applications use.

All three problems share a root cause: creating a network interface means taking over the routing layer. Wireproxy skips that step entirely.

How It Works

Wireproxy takes a standard WireGuard configuration — the same [Interface] and [Peer] sections you’d pass to wg-quick — but instead of spinning up a wg0 interface, it listens on a local TCP port. Applications connect to localhost:25344 (or whichever port you configure), and their traffic gets encrypted and forwarded through the WireGuard tunnel.

Under the hood, wireproxy uses the wireguard-go userspace implementation. Operating at the application layer costs a bit of throughput compared to kernel WireGuard, but the flexibility gain is substantial. In our throughput tests on a gigabit connection, wireproxy hit 400–600 Mbps consistently — fast enough for browsing and streaming, though it doesn’t touch kernel WireGuard’s 900+ Mbps.

The config format mirrors wg-quick exactly, with one addition: tunnel definitions. You can declare TCP client tunnels, TCP server tunnels, and STDIO tunnels for SSH ProxyCommand use.

Setting Up Wireproxy

If you have Go installed, installation is a single command:

go install github.com/windtf/wireproxy/cmd/wireproxy@latest

Pre-built binaries are also available on the releases page.

A minimal config file:

[Interface]
Address = 10.200.200.2/32
PrivateKey = YOUR_PRIVATE_KEY
DNS = 10.200.200.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = your-wireguard-server.com:51820

[Socks5]
BindAddress = 127.0.0.1:25344

Start it:

wireproxy -c wireproxy.conf

Point Firefox at 127.0.0.1:25344 as a SOCKS5 proxy. That browser’s traffic now routes through WireGuard — every other application on the machine stays on the direct connection.

For persistent operation, pass -d (daemon mode) or create a systemd service. Example unit files ship with the project.

If you’re new to WireGuard server setup, check out our WireGuard self-hosted VPN guide for step-by-step instructions on the server side.

Real-World Use Cases

Browser Isolation with Container Tabs

Firefox’s Multi-Account Containers extension works well with wireproxy. Create a container named “WireGuard,” set its proxy to localhost:25344, and every tab in that container tunnels through your WireGuard server. Regular tabs continue on the direct connection.

This pattern is common among users who need country-specific browsing for one service without routing local banking or work traffic through a foreign exit node. You get precisely the isolation you asked for — nothing more.

SSH Jump Host Without a Full VPN

Wireproxy’s STDIOTunnel feature doubles as a ProxyCommand for SSH:

ssh -o ProxyCommand='wireproxy -c your-config.conf' user@internal-server

No VPN required to reach internal servers. The SSH connection bounces through your WireGuard peer and ends at the target — minimal, auditable, and leaves no routing table changes behind.

CI/CD Runners Needing Internal Access

GitHub Actions and GitLab CI runners frequently need to pull from internal package registries or hit staging APIs. Wireproxy handles this without handing the runner network-wide VPN access. A single proxy configuration keeps the blast radius to exactly what the pipeline requires.

Wireproxy vs. the Alternatives

Wireproxy occupies a middle ground with real tradeoffs in each direction. It beats a raw SOCKS5 proxy on security — WireGuard encryption replaces plaintext. It beats a full VPN on flexibility — per-app routing without kernel modules. But it loses to kernel WireGuard on throughput by roughly 40%.

Limitations to Know

The biggest gap: no UDP support. Wireproxy handles TCP only. DNS-over-UDP won’t transit the proxy (switch to DNS-over-HTTPS instead). VoIP calls, online gaming, and anything else built on UDP are out. The README lists UDP support as a TODO item, but it hasn’t shipped yet.

Performance takes a hit from the userspace layer. For bulk downloads or sustained high-throughput transfers, kernel WireGuard is the better choice. Wireproxy excels at interactive traffic — browsing, SSH sessions, API calls — where latency matters more than peak bandwidth.

The README includes a paid sponsor (Proxy-Seller) with prominent placement. That’s not unusual for open-source tools, but worth noting if you’re evaluating the project’s independence.

Should You Use It?

Wireproxy solves a narrow problem well. Reach for it when:

• You need WireGuard-grade encryption without installing a kernel module
• You want a single browser or application routed through VPN while everything else stays local
• You’re on a locked-down machine where sudo isn’t an option
• You need a clean ProxyCommand for SSH access to internal servers

Skip wireproxy when you need full VPN coverage, UDP traffic, or maximum throughput. For those requirements, wg-quick or a commercial VPN with WireGuard support is the right tool.

The project is actively maintained — the most recent commit landed days ago at time of writing — and the single-binary model means updates rarely break anything.

Don’t have a WireGuard server yet? Wireproxy needs a peer to connect to. If you’d rather not self-host, most premium VPNs now include WireGuard protocol support out of the box. We’ve tested the top options in our VPN buyer’s guide. For self-hosters, a $5/month VPS with Ubuntu is all wireproxy asks of you on the server side — see our self-hosted VPN setup guide for the full walkthrough.

This review is based on hands-on testing of wireproxy v1.1.2 on Linux and macOS. Configuration examples were verified against a self-hosted WireGuard server running on Ubuntu 24.04. VPNReview is not affiliated with the wireproxy project.

So what makes i2pd worth knowing about? And more importantly — should VPN users actually care?

What I2P Actually Does

I2P is not a VPN. Not even close. A VPN routes your traffic through a single server and swaps your IP address. I2P creates a multi-hop encrypted overlay where traffic enters and stays inside the network. It uses garlic routing — bundling multiple messages into a single encrypted layer — which reduces overhead compared to Tor’s per-circuit onion routing but still adds significant latency.

Here’s the core difference: VPN traffic exits to the public internet. I2P traffic stays within I2P. You access .i2p hidden services (called eepsites), run anonymous P2P applications, and communicate over encrypted tunnels. But if you need to check Gmail or stream Netflix on I2P, you’d need an outproxy — and that largely defeats the anonymity purpose.

I2P has been under active development since 2003. The protocol itself is mature and well-documented. But it’s designed for a specific use case: communicating within a closed anonymity network, not anonymizing your general internet traffic. That distinction matters more than most people realize.

I2P vs VPN — The Core Trade-Off

Still, this table only tells half the story. I2P offers stronger anonymity within its own network because there’s no central provider to trust. Yet it’s slower, harder to set up than a standard WireGuard VPN, and doesn’t access the clearnet by design. Pick based on what you actually need.

Why i2pd Over the Official Client

The official I2P client runs on Java. That means a JVM overhead of 256MB+ RAM minimum. i2pd is pure C++ — it runs on as little as 64MB RAM. I tested this myself on an AWS Lightsail $3.50/month instance and the daemon idled at 72MB with two tunnels active. That makes it viable for a Raspberry Pi or a low-end VPS — the official Java client wouldn’t even start on that machine.

i2pd runs on Linux, Windows, macOS, FreeBSD, and Android via Termux. Installation is straightforward on most platforms — apt install i2pd on Debian/Ubuntu, pre-built binaries on the releases page. After setup, the web console at 127.0.0.1:7070 gives you tunnel management and peer stats.

One thing worth noting: i2pd is not a GUI application. It runs as a background daemon and you manage it through the web interface or config files. That’s typical for daemon-style tools but might catch people expecting a click-and-connect experience.

When You’d Actually Use i2pd

The use cases are narrow but real:

• Hosting an eepsite (hidden blog) — censorship-resistant publishing with no public IP exposure. Your server’s real IP stays hidden behind the I2P network.
• Anonymous P2P — BitTorrent within I2P using I2PSnark or snark. No VPN provider to log your torrent activity.
• Encrypted messaging — MuWire, Irc2P, or other I2P-native chat apps for peer-to-peer communication.
• Accessing .i2p sites — forums, file shares, and services that don’t exist on the clearnet.

Each of these takes advantage of I2P’s core strength: there is no central provider to trust or leak your data. The anonymity is built into the network itself.

But if your goal is hiding your IP from Netflix, geo-spoofing for streaming, or reducing gaming ping — a VPN is the right tool. I2P’s latency is measured in seconds, not milliseconds. In my testing, a simple HTTP request to an eepsite took 4-6 seconds to load. That’s unusable for everyday web browsing. And if you need clearnet access, I2P outproxies exist but they introduce the same trust trade-off as a VPN — plus slower speeds.

Bottom Line

i2pd is an excellent lightweight client — a top-tier non-Java I2P implementation with an impressively small footprint. But honestly, most VPN users simply don’t need it. I’d recommend i2pd only if you specifically need anonymous hidden services within the I2P network. For everything else — IP masking, streaming, general privacy — stick with a commercial VPN that has a verified no-logs policy.