# UDPspeeder: Forward Error Correction for Lossy UDP Links

> UDPspeeder wraps a UDP service or a UDP-based VPN and adds Reed-Solomon FEC to hide packet loss. It is a Linux-only tunnel with a small option surface, and it trades bandwidth for a lower loss rate.

**wangyu-/UDPspeeder** — Project brief: A Tunnel which Improves your Network Quality on a High-latency Lossy Link by using Forward Error Correction, possible for All Traffics(TCP/UDP/ICMP).

- Repository: https://github.com/wangyu-/UDPspeeder
- Stars: 5,172 · Forks: 857
- Language: C++
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/wangyu-udpspeeder

## What UDPspeeder is for, and who it is not for

UDPspeeder is a tunnel that sits in front of a UDP service and reduces the packet loss rate on a high-latency, lossy link. The README states the goal directly: with well-tuned parameters you can reduce IP or UDP/ICMP packet-loss-rate to less than 0.01%, and it adds that UDPspeeder can also improve TCP latency and TCP single-thread download speed.

That second claim only holds in combination. Used alone, the README says UDPspeeder improves only UDP connections. To cover TCP and ICMP you pair it with any UDP-based VPN; the README lists OpenVPN, L2TP and ShadowVPN as confirmed to work. So the realistic audience is someone who already runs a UDP VPN or a UDP service and wants the loss rate on the underlying link to stop hurting them.

The tool is not a general-purpose accelerator and it is not a replacement for a VPN. If your traffic is plain TCP with no UDP tunnel underneath, UDPspeeder alone does nothing for it.

## Reed-Solomon FEC and the -fec ratio

The mechanism is forward error correction with Reed-Solomon codes. The README quotes the standard description: by adding t check symbols to the data, a Reed-Solomon code can detect any combination of up to t erroneous symbols, or correct up to floor(t/2) symbols. As an erasure code it can correct up to t known erasures.

In practice you do not set t directly. You set a ratio with -f, written x:y, and the README explains the example -f20:10 as sending 10 redundant packets for every 20 original packets. That is the whole trade: the receiver can reconstruct missing originals from the redundant ones, and you pay for it in bandwidth. The overhead is proportional to y/x, so -f20:10 costs roughly 50% more traffic on the wire.

The tunnel is not a single process. The repository has separate tunnel_client.cpp and tunnel_server.cpp sources, a fec_manager, delay_manager, connection and packet modules, and the default branch is branch_libev, which points at the libev event loop used for the I/O path. FEC state is therefore per connection, not global.

## Installing from the release page and a first run

The README gives exactly one installation route: download a binary release from https://github.com/wangyu-/UDPspeeder/releases. There is no package manager instruction and no build-from-source section in the README, although the repository does contain a CMakeLists.txt and a makefile for anyone who wants to compile it.

Supported platforms are Linux hosts, which the README spells out as desktop Linux, Android phone or tablet, OpenWRT router, or Raspberry PI. For Windows and macOS the README points to a 7.5mb virtual machine image hosted in the udp2raw-tunnel releases, which is a heavier answer than a native build.

The first real use is a UDP service. Assume your server is 44.55.66.77 and something is listening on UDP port 7777. Start the server side of the tunnel first:

```bash
./speederv2 -s -l0.0.0.0:4096 -r 127.0.0.1:7777  -f20:10 -k "passwd"
```

## Wiring the client side and what the ports mean

The server side above listens on 0.0.0.0:4096 and forwards decoded traffic to 127.0.0.1:7777, which is the local UDP service. Now start the client, pointing at the server's public address and the port the server opened:

```bash
./speederv2 -c -l0.0.0.0:3333  -r44.55.66.77:4096 -f20:10 -k "passwd"
```

The README states the result plainly: connecting to UDP port 3333 at the client side is equivalent to connecting to port 7777 at the server side, and the connection has been boosted by UDPspeeder. Both ends must share the same -k value, which the README describes as simple XOR encryption and which it lists under options that must be the same on both sides. Note that the server side is the one that reaches the real service, so 127.0.0.1:7777 in the server command refers to the service on the server host, not on your client machine.

## Tuning at runtime with the --fifo option

The README documents a named pipe for sending commands to a running process, via --fifo fifo.file. The commands listed are fec, mtu, timeout, queue-len and mode, each taking a value. For example:

```bash
echo fec 19:9 > fifo.file
echo mtu 1100 > fifo.file
echo timeout 5 > fifo.file
echo queue-len 100 > fifo.file
echo mode 0 > fifo.file
```

This matters because the right FEC ratio depends on the loss pattern you actually see, and the README does not offer a way to measure that for you. You set a value, observe the result, and adjust. The fact that fec, mtu and timeout are all runtime-settable suggests the author expected this loop to be normal operation, not a one-time setup step.

## Where UDPspeeder is the wrong tool

The clearest limitation is stated by the README itself: used alone, UDPspeeder improves only UDP connections. If you are trying to fix packet loss for a plain TCP application and you are not willing to put a UDP VPN underneath, this project does not address your problem.

Platform support is the second boundary. Linux only, with Windows and macOS users pushed toward a virtual machine image. On a router or a Raspberry Pi that is fine. On a Windows desktop it is an awkward fit.

There is also an interaction the README does not resolve. FEC adds redundant packets, which increases the size of the flow, and the tunnel exposes an mtu command through the fifo interface. The README does not document how the FEC ratio and MTU settings should be chosen together, and it does not document rollback if a settings change makes things worse. Treat both as things you verify on your own link.

Finally, the project's last push was on 2023-02-07, and the most recent release is 20230206.0 from the same date. That is not an archived repository, but it is also not a project with recent activity, so expect to rely on the existing documentation and the wiki.

## UDPspeeder against kcptun, and the sibling projects

The natural comparison is kcptun, which people search for directly. The difference is in the correction strategy: UDPspeeder uses Reed-Solomon FEC, sending redundant packets up front so the receiver can reconstruct losses without asking. kcptun is built on KCP, which is an ARQ-style protocol that retransmits lost data more aggressively than TCP. FEC pays bandwidth continuously and does not add a round trip when a packet is lost; ARQ pays only when loss happens but needs the retransmission to arrive. On a long, lossy link the FEC approach avoids waiting for a round trip, which is the reason UDPspeeder can help latency as well as loss rate.

The README also names two sibling projects by the same author. tinyfecVPN is described as a lightweight high-performance VPN with UDPspeeder's function built in, which removes the need to pair UDPspeeder with a separate VPN. udp2raw is recommended alongside UDPspeeder to get better speed on ISPs that apply UDP QoS or throttling. If your link is being throttled rather than losing packets, udp2raw addresses a different problem than FEC does.

## Conclusion

Adopt UDPspeeder if you run a Linux host or router in front of a UDP service or a UDP VPN and you can spare the extra bandwidth that -f20:10 implies. Skip it if you need a single tool that also covers TCP and ICMP without a VPN, or if you cannot run a Linux binary on the endpoint. Before committing, check the release page for a build matching your device, confirm both ends can share the same -k value, and test the -fec ratio against your real loss pattern, since the README does not document how the FEC ratio interacts with MTU.

## FAQ

### How do I fix UDP packet loss?

UDPspeeder addresses this with Reed-Solomon forward error correction: you set a ratio such as -f20:10, meaning 10 redundant packets for every 20 originals, and the receiver reconstructs losses from the redundancy. The README states that with well-tuned parameters you can reduce IP or UDP/ICMP packet-loss-rate to less than 0.01%, at the cost of additional bandwidth.

### Should I use UDP or TCP for my VPN?

The README does not compare the two directly, but it does note that UDPspeeder works with UDP-based VPNs and lists OpenVPN, L2TP and ShadowVPN as confirmed to work. If you choose a UDP VPN, UDPspeeder can sit underneath it and add FEC to the tunnel traffic.

### Is UDP or TCP better for gaming?

The README does not discuss gaming. It does state that UDPspeeder improves UDP connections when used alone, and that any UDP-based VPN combined with UDPspeeder can improve TCP, UDP and ICMP traffic together.

### Is OpenVPN TCP or UDP better?

The README does not answer this. It only lists OpenVPN among the UDP-based VPNs confirmed to work with UDPspeeder, and links to a separate wiki page titled UDPspeeder + openvpn config guide.

## Sources

- [Official README](https://github.com/wangyu-/UDPspeeder#readme)
- [Project repository](https://github.com/wangyu-/UDPspeeder)
- [Release notes](https://github.com/wangyu-/UDPspeeder/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wangyu-udpspeeder