frp’s Reachability Model: Turning Outbound Connections into Public Service
frp is a reverse proxy for making a service inside a private network reachable through a machine with a public address. The important question is not simply how to “get through NAT,” but how frp turns an outbound relationship into controlled reachability: where a public request arrives, who keeps the private-side connection alive, what kind of traffic is allowed through it, and which path carries the bytes. This opening establishes that model so the rest of this series can examine frp’s lifecycle, proxy modes, performance choices, direct-path attempts, and security boundaries without treating them as unrelated features.
The inbound request a private network cannot receive
Consider a web application running on a machine in a home lab or corporate LAN. The machine has a private address, and its network edge performs NAT or blocks unsolicited inbound connections. A browser on the Internet can send a request to a public IP, but that packet has no ordinary route to the application. The application can initiate connections outward, yet it cannot normally announce a listening socket that the Internet can reach merely by existing.
frp changes the direction of the durable connection. An operator places frps on a server with a public IP address and runs frpc beside the private service. The client reaches out to the server, creating a connection that the private network is already willing to allow. When an Internet user later contacts the public server, frps sends the request through the relationship that frpc has established. The private service remains private in the addressing sense; the public server becomes the place where the request enters the system.
That distinction matters. frp is not assigning the local machine a public address, rewriting the Internet’s routing table, or asking the firewall to accept every new inbound flow. It is arranging for a private-side participant to maintain a usable path to a public rendezvous point. The reverse-proxy part is precisely this reversal of initiative: the backend side establishes the durable connection, while the public-facing side receives the request.
The network edge typically sees an ordinary outbound conversation. NAT can create state for the private client’s connection to the public server, and the firewall can allow return traffic that belongs to that state. Once the relationship exists, frp can associate a later public request with it. This is why the design depends on liveness and reconnect behavior: a quiet, broken, or expired client relationship is not repaired by the existence of a public IP alone. It is also why the public server is part of the design from the beginning rather than an optional observer. It supplies the stable side of the conversation to which private clients can connect.
That arrangement is useful precisely because it respects an existing boundary, but it does not make the boundary irrelevant. A restrictive network may block the chosen transport, a public server may have insufficient ports or bandwidth, and a local service may reject or mishandle the forwarded connection. frp changes the path available to the request; it does not guarantee that every layer above or below the proxy will accept it.
One public rendezvous, one private service owner
The basic topology has four roles. An Internet user supplies a public request. frps receives it and applies the server-side proxy and policy model. frpc owns the connection into the private environment. A local SSH server, web application, database, or other TCP/UDP service supplies the final endpoint. The public server does not need to discover the local service by scanning the private network; the client declares which local service it is willing to represent.
This is why the distinction between the server’s control port and an exposed service port is useful. A client may connect to frps on one port to establish the frp relationship, while a configured proxy makes a different public port or virtual host represent the local service. A request arriving at the latter is not a new frp session in the conceptual model. It is demand placed on an already registered relationship.
The relationship also has an owner. frpc is not just a passive pipe: it carries the client’s identity and proxy definitions, maintains liveness, and decides which local address and port a proxy represents. frps owns public ingress, shared resources, and the mapping from public requests to registered proxies. That division lets one public server serve several private environments, but it also makes the public server a meaningful trust and availability boundary. If it is unavailable, misconfigured, or overloaded, ordinary relayed access is affected even when every local service is healthy.
The ownership model becomes clearer when the same public server represents different kinds of local work. An engineer might use a TCP proxy to reach SSH on a development machine, an HTTP proxy to share a preview site under a domain, and a private visitor proxy to let a second authorized client reach an internal service without giving the whole Internet a listening port. In each case, the local client chooses the endpoint and the server supplies the public or coordinated entry point. The visible address is therefore not the whole permission model: it tells a caller where to start, while the proxy mode and authentication rules determine what the caller can actually become connected to.
This also explains why a single frps instance can be both convenient and consequential. Centralizing public listeners makes naming, port allocation, monitoring, and policy possible across many clients. It also concentrates the cost of relayed traffic and the consequences of a server-side mistake. A design that is easy to reach can still be a poor design if it exposes a management interface, uses a broad visitor rule, or treats the public server as an unlimited resource.
The word “controlled” in controlled reachability therefore does real work. Reachability has at least four dimensions:
- Entry point: a public TCP/UDP port, an HTTP(S) domain and route, a shared TCP-multiplexing listener, or an internal visitor path.
- Traffic semantics: raw bytes, datagrams, or requests whose host, path, and headers can be interpreted by the proxy.
- Audience: anyone who can reach a public listener, a separately authenticated application user, or a visitor authorized to use a private proxy.
- Path: traffic relayed through
frps, or—where the NAT conditions allow it—a direct path attempted between clients.
Thinking in these dimensions is more reliable than thinking of frp as one universal tunnel. A public TCP proxy for SSH and a secret TCP proxy for a private administrative service both carry bytes, but they do not create the same exposure. An HTTP proxy can route by domain and URL location; a raw TCP proxy cannot. An XTCP attempt can change the payload path, but it does not remove the need for frp’s coordination and authorization model.
Relay and direct are different outcomes
The ordinary frp picture is a relay. A public request arrives at frps, crosses the established relationship to frpc, and reaches the local service. The relay costs the public server bandwidth and makes it part of the data path, but it offers a predictable rendezvous point. It is often the simplest choice when the two private endpoints sit behind incompatible NATs, when policy requires traffic to pass through a managed server, or when a stable public address matters more than avoiding an extra hop.
frp also includes XTCP, which attempts a different outcome for suitable client pairs. The server helps the endpoints exchange the network information and probing behavior needed for NAT hole punching. If the attempt succeeds, the endpoints can build a direct KCP or QUIC-based tunnel for the payload. frps is still needed for discovery, coordination, and the initial authorization relationship; “P2P” describes the eventual data path, not an architecture with no server.
The qualification is essential because NAT behavior is not uniform. The source explicitly notes that XTCP may not work with all NAT devices and recommends a fallback such as STCP when it fails. A direct path is therefore an opportunity selected under conditions, not a guarantee that frp has defeated every firewall. The system must be designed so that the relay path, or a different visitor mode, remains an acceptable result.
The distinction also changes how to think about visibility and cost. In a relayed design, frps is an intentional observation and resource point: it receives the public connection, coordinates the corresponding client-side work, and carries the forwarded traffic. In a successful direct design, the payload may avoid that relay, but the endpoints still learned enough from the coordination service to try the connection, and the service still depends on the authorization relationship that made the attempt legitimate. Directness can reduce a hop and make better use of client bandwidth, yet it introduces more environmental conditions than a fixed public listener. The right comparison is not “relay bad, P2P good”; it is predictable centralized path versus conditional distributed path, chosen for the service and its trust boundary.
What frp does—and does not—promise
The simplest frp modes provide service-level reachability, not automatically a routed connection to an entire private network. A TCP proxy can represent an SSH listener; an HTTP proxy can represent a web service; a UDP proxy can carry datagrams. That does not mean an Internet user can browse arbitrary private addresses or reach every port beside the configured service. The boundary is the proxy definition and the local endpoint that accepts the forwarded traffic.
This is also why frp should not be casually described as a VPN. The repository now contains an alpha VirtualNet feature that uses a TUN interface to support IP-level routing, but its documentation marks it unstable, platform-limited, permission-dependent, and unsuitable for production use. That feature extends the model; it does not erase the scope and caveats of the ordinary port and protocol proxies.
Nor does public reachability equal authorization. A domain or port that points at frps is an entry point, not proof that the application is protected. frp provides session authentication, TLS-related controls, private visitor modes, and other policy mechanisms, but the correct combination depends on what is being exposed and who should use it. Application authentication, least-privilege routing, strong secrets, and careful server configuration still matter. A public dashboard or an administrative service can be risky even when the tunnel itself is functioning exactly as designed.
The useful mental model is therefore not “private service plus magic tunnel.” It is a small system of negotiated boundaries:
- A public rendezvous receives traffic that the private service could not receive directly.
- An outbound client relationship gives the private side a durable, owned path back to that rendezvous.
- A proxy contract states what protocol and local service are represented.
- An admission decision determines who can create the relationship and who can use it.
- A path choice determines whether bytes are relayed through the public server or an attempted direct session is used.
The next question is how this system preserves identity and allocates capacity once a public request arrives. The answer lies in the separation between a control connection and request-specific work connections: a distinction that explains both frp’s flexibility and many of its operational failure modes.