Noureddine RAMDI / frp: a fast, extensible reverse proxy evolving towards cloud-native architecture

Created Sun, 26 Apr 2026 17:51:11 +0000 Modified Sat, 23 May 2026 20:41:27 +0000
921 Words
github-stars go reverse-proxy nat-traversal networking cloud-native

fatedier/frp

Reverse proxies are a staple in network infrastructure, but exposing local servers behind NATs or firewalls to the public internet reliably and efficiently remains a challenge. frp tackles this problem with a straightforward yet powerful approach: a fast reverse proxy written in Go that supports multiple protocols and even peer-to-peer connection modes. What’s especially interesting is the planned V2 overhaul, which aims to re-architect frp as a cloud-native, extensible platform inspired by Kubernetes and Envoy — a significant departure from traditional proxy design.

What frp is and how it works

frp is a reverse proxy tool designed to expose local servers behind NATs or firewalls to the internet without complex network reconfiguration. Written entirely in Go, it supports TCP, UDP, HTTP, and HTTPS protocols, allowing users to forward traffic from public endpoints to internal services.

Under the hood, frp operates with two main components: frps (the server) and frpc (the client). The server component runs on a public-facing machine with a static IP or domain, while the client runs on the local machine behind NAT or firewall. The client establishes a persistent connection to the server, allowing inbound traffic to be proxied back to the local service.

One of frp’s standout features is its support for P2P connect mode. This enables a direct connection between client and server peers without routing traffic through the central server, reducing latency and bandwidth usage. The protocol stack covers TCP and UDP forwarding, along with HTTP/HTTPS domain-based forwarding, making it versatile for a range of applications — from accessing private web dashboards to exposing development environments or IoT devices.

The project is actively maintained, with the current V1 branch focusing on stability and incremental improvements. The codebase leverages Go’s concurrency model and standard library networking features effectively, resulting in a clean and maintainable code structure.

The architectural evolution and technical strengths

What sets frp apart technically is not just its current capability but the ambitious architectural rethink planned for V2. The upcoming version aims to transform frp into a modern four-layer (network) and seven-layer (application) proxy platform, drawing inspiration from cloud-native patterns found in Kubernetes and ServiceMesh architectures.

This means moving beyond a simple reverse proxy to a proxy platform with strong extensibility, scalability, and observability baked in. The V2 design includes concepts like Custom Resource Definitions (CRDs) and controllers, akin to Kubernetes, which allow dynamic configuration and control plane APIs. It also plans to support advanced features such as load balancing, traffic shaping, and more sophisticated routing logic.

The tradeoff here is clear: V2 will introduce breaking changes and increased complexity compared to the straightforward V1 implementation. However, this complexity is necessary to meet the demands of modern distributed systems and cloud environments. The project is wisely maintaining the V1 branch for users who prioritize stability and backward compatibility.

From a code quality perspective, the current V1 is surprisingly clean for a high-star open source project. The Go code follows idiomatic practices, with clear modular separation between the proxy logic, protocol handling, and configuration. Extensive use of interfaces and abstraction layers prepares the groundwork for the extensible architecture planned in V2.

The P2P connect feature is also worth noting technically. It leverages direct peer connections where possible, avoiding the overhead of centralized routing. This can significantly improve performance and reduce server load, especially in scenarios with many clients or high traffic volumes.

Quick start

./frps -c ./frps.toml
./frpc -c ./frpc.toml
ssh -oPort=6000 test@x.x.x.x
ssh -o 'proxycommand socat - PROXY:x.x.x.x:%h:%p,proxyport=5002' test@machine-a.example.com
ssh -o 'proxycommand socat - PROXY:x.x.x.x:%h:%p,proxyport=5002' test@machine-b.example.com

This minimal quick start sequence launches the server and client with their respective configuration files and demonstrates SSH access through the proxy, including using socat for proxy command chaining.

who should consider using frp

frp is a solid choice for developers and ops teams who need to expose internal services behind NATs or firewalls without complex VPN setups or firewall rules. Its support for multiple protocols and P2P mode makes it versatile for everything from remote development to IoT access.

The upcoming V2 promises to elevate frp from a simple reverse proxy to a cloud-native proxy platform with extensibility and scalability at its core. If you are looking for a proxy solution that will evolve alongside cloud-native trends and want to experiment with advanced proxy features, keeping an eye on V2 is worthwhile.

That said, the V2 changes are breaking and will require adaptation. For production environments where stability and simplicity matter most, the current V1 release remains a trustworthy option.

Overall, frp balances practical utility with ambitious future plans, making it worth understanding for anyone working with network proxies in complex environments.

→ GitHub Repo: fatedier/frp ⭐ 106,104 · Go