1. Introduction
During software development and testing phases, it often becomes necessary to make local server services operating under private IP addresses accessible from external networks. To address this challenge, FRP (Fast Reverse Proxy) provides an easy-to-configure, high-performance reverse proxy solution.
FRP features a built-in web-based dashboard for real-time monitoring of active tunnel connections, traffic statistics, and system health. Configuration details and system architecture for FRP deployment:
2. FRP Overview
2.1 Definition
FRP is a reverse proxy application designed to securely expose local servers behind NAT (Network Address Translation) or restrictive firewalls to the public internet. It acts as a relay for external user access to local services on machines that do not have a public static IP address.
2.2 Core Components
FRP client-server architecture binaries:
frps(FRP Server): Runs on a cloud server or similar host with a public IP address. It functions as a listener waiting for connection requests from clients and external users.frpc(FRP Client): Runs on the local server within the private network where the actual target services (SSH, web server, database, etc.) are running. It establishes an outbound connection tofrpsto build a secure tunnel.
+------------------+ +------------------+ +------------------+
| Local Server | | Public Server | | External User |
| (FRP Client) | --[Outbound]--> | (FRP Server) | <---[Inbound]--- | (SSH/Browser) |
| [frpc] | | [frps] | | |
+------------------+ +------------------+ +------------------+
2.3 Operating Principle and Workflow
Traffic routing steps via FRP:
- Connection Establishment:
frpcwithin the private network initiates an outbound connection tofrpson the public cloud. Because it is an outbound connection, it can bypass most inbound firewall rules and NAT restrictions. - Port Binding: Upon receiving the connection,
frpsbinds the specified port (e.g., port3500) and prepares to forward inbound traffic to that port tofrpcvia the active tunnel. - Data Transfer: When an external user attempts to connect to
CLOUD_PUBLIC_IP:3500on the public server,frpsintercepts the traffic and forwards it tofrpcthrough the established tunnel. - Response Return:
frpcreceives the forwarded data and passes it to the local service (such as an SSH daemon on port22). It collects the response from the service, sends it back tofrpsthrough the tunnel, and it is ultimately delivered to the external user.
2.4 Key Features
- Multi-protocol Support: Supports TCP, UDP, HTTP, HTTPS, and domain-based virtual host routing.
- P2P Connection (
xtcp): Supports a peer-to-peer communication mode directly between clients without going through a relay server after the initial handshake, saving bandwidth. - Security Features: Supports in-tunnel encryption, data compression, and token-based authentication.
- Management Dashboard: Provides a Web UI to visualize tunnel status and bandwidth usage.
3. Installation
Obtain the release package corresponding to the target system’s architecture from the official repository.
- Reference Source: FRP GitHub Releases
- Verified Version:
0.67.0(Assuming a Linux 64-bit environment)
Binary extraction commands for server and client:
# FRPパッケージのダウンロードと展開
wget https://github.com/fatedier/frp/releases/download/v0.67.0/frp_0.67.0_linux_amd64.tar.gz
tar -zxvf frp_0.67.0_linux_amd64.tar.gz
cd frp_0.67.0_linux_amd64
4. Server-Side Configuration
💡 Target Host: Cloud server with a public IP address
4.1 Editing the Configuration File (frps.toml)
Server configuration using TOML format (v0.52.0 and later):
# 設定ファイルの配置ディレクトリ作成と編集
mkdir -p /etc/frp
cp frps.toml /etc/frp/frps.toml
vi /etc/frp/frps.toml
Configuration parameters for the server:
# frps.toml
bindPort = 7000
auth.token = "your_secure_token"
# 管理ダッシュボードの設定
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "admin_password"
4.2 Firewall Configuration
In your cloud provider’s security groups and local firewall (ufw or firewalld), allow inbound traffic to the following ports:
- Port
7000: Required for the control connection betweenfrpcandfrps. - Port
7500: Required to access the management dashboard. - Service Ports: Any ports requested by
frpcfor public exposure (e.g.,6000,6500, etc.).
4.3 Background Execution Configuration with systemd
Register as a systemd service to enable automatic recovery upon server reboot or abnormal process termination.
# systemdサービスファイルの作成
sudo vi /etc/systemd/system/frps.service
Service definition for systemd:
[Unit]
Description=FRP Server
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
Enable and start the service.
# バイナリのシステムパスへの配置
sudo cp frps /usr/local/bin/
# サービスの有効化および起動
sudo systemctl daemon-reload
sudo systemctl enable frps
sudo systemctl start frps
sudo systemctl status frps
4.4 Verifying the Dashboard
Dashboard access and credential verification:
- URL:
http://CLOUD_PUBLIC_IP:7500 - Username:
admin - Password:
admin_password
5. Client-Side Configuration
💡 Target Host: Local server with a private IP address
5.1 Editing the Configuration File (frpc.toml)
Client configuration for destination server and local services:
# 設定ファイルの配置ディレクトリ作成と編集
mkdir -p /etc/frp
cp frpc.toml /etc/frp/frpc.toml
vi /etc/frp/frpc.toml
Client configuration parameters:
# frpc.toml
serverAddr = "CLOUD_PUBLIC_IP"
serverPort = 7000
auth.token = "your_secure_token"
[[proxies]]
name = "ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6000
5.2 Background Execution Configuration with systemd
Systemd service construction for the client:
# systemdサービスファイルの作成
sudo vi /etc/systemd/system/frpc.service
[Unit]
Description=FRP Client
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/frpc -c /etc/frp/frpc.toml
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
Enable and start the client service.
# バイナリのシステムパスへの配置
sudo cp frpc /usr/local/bin/
# サービスの有効化および起動
sudo systemctl daemon-reload
sudo systemctl enable frpc
sudo systemctl start frpc
sudo systemctl status frpc
6. Advanced Configuration and Security
6.1 Generating a Secure Authentication Token
To prevent unauthorized access to the FRP control port, it is recommended to use a cryptographically secure random token. Generation of a 24-character Base64 encoded string using OpenSSL:
# 安全なランダムトークンの生成
openssl rand -base64 24
6.2 Exposing Multiple Ports and Services
Definition of multiple [[proxies]] blocks in frpc.toml:
# frpc.toml (複数サービス構成例)
serverAddr = "CLOUD_PUBLIC_IP"
serverPort = 7000
auth.token = "your_secure_token"
[[proxies]]
name = "ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6000
[[proxies]]
name = "web"
type = "tcp"
localIP = "127.0.0.1"
localPort = 80
remotePort = 6500
After changing the configuration, restart the client service.
# クライアントサービスの再起動
sudo systemctl restart frpc
⚠️ Note: You must allow inbound communication for all exposed remotePorts (e.g., 6000, 6500) on the public server’s firewall.
6.3 Specifying Port Ranges in Bulk
Bulk port exposure using ranges or commas:
# frpc.toml (ポート範囲指定例)
[[proxies]]
name = "range_ports"
type = "tcp"
localIP = "127.0.0.1"
localPort = "8000-8080"
remotePort = "8000-8080"
6.4 Restricting Bind Ports on the Server Side
Server-side bind port restrictions:
# frps.toml (ポート制限設定)
allowPorts = [
{ start = 6000, end = 7000 }
]
6.5 Connection Troubleshooting
If you cannot connect despite having no issues with the configuration, packet filtering on the public server side may be the cause.
Step 1: Explicitly Allowing Port 7000 with iptables
Insertion of a rule at the top of the input chain:
# ポート7000の通信を許可
sudo iptables -I INPUT -p tcp --dport 7000 -j ACCEPT
Step 2: Persisting the Rules
Persistence of rules using iptables-persistent:
# ルールの永続化保存
sudo DEBIAN_FRONTEND=noninteractive apt-get install -y iptables-persistent
sudo netfilter-persistent save
Step 3: Verifying Connectivity from the Outside
Connectivity verification using netcat (nc):
# 外部端末からの疎通テスト
nc -zv CLOUD_PUBLIC_IP 7000
7. STCP (Secure TCP) Configuration
Standard TCP proxies globally expose ports on the public server side, making them susceptible to port scanning and unauthorized access. In an STCP (Secure TCP) configuration, no public ports are exposed on the public server; instead, communication is routed through an encrypted tunnel. The accessing client terminal (Visitor) also runs frpc and binds to a local port to relay the traffic.
+------------------+ +------------------+ +------------------+
| Service Host | | Public Server | | Visitor Host |
| (FRP Client) | --[STCP Tunnel]->| (FRP Server) | <-[STCP Tunnel]- | (FRP Client) |
| [frpc (service)]| | [frps] | | [frpc (visitor)]|
+------------------+ +------------------+ +------------------+
7.1 STCP Architectural Configuration
- Service (Private Server): Runs the target service to be exposed and the
frpcacting as the STCP provider. - frps (Relay Server): Runs on a public IP and relays communication without directly exposing ports to the outside.
- Visitor (Accessing Terminal): Runs on the developer’s local PC or similar, running
frpcas an STCP visitor to bind a local port.
7.2 Configuration Files in INI Format
Configuration examples in INI format:
1. Service Provider Configuration (frpc_service.ini)
Placed on the private server side.
# frpc_service.ini
[common]
server_addr = CLOUD_PUBLIC_IP
server_port = 7000
token = your_secure_token
[ssh_stcp]
type = stcp
sk = secret_key_here
local_ip = 127.0.0.1
local_port = 22
⚠️ Security Note: The secret key (sk) functions as a pre-shared key for the tunnel. Set a unique, complex string for each service.
2. Relay Server Configuration (frps.ini)
Placed on the public server side.
# frps.ini
[common]
bind_port = 7000
token = your_secure_token
3. Visitor Configuration (frpc_visitor.ini)
Placed on the accessing local PC side.
# frpc_visitor.ini
[common]
server_addr = CLOUD_PUBLIC_IP
server_port = 7000
token = your_secure_token
[ssh_stcp_visitor]
type = stcp
role = visitor
server_name = ssh_stcp
sk = secret_key_here
bind_addr = 127.0.0.1
bind_port = 6000
7.3 Connection Establishment
When the STCP configuration is active, you connect to your own loopback address to access the remote service from the visitor terminal.
Connection address for a remote application on port 4000:
# ビジター端末からの接続実行例
ssh -p 6000 [email protected]
(*Please specify an appropriate loopback address, such as 127.0.0.1:6001, depending on your network environment’s bind settings.)
7.4 Binary Startup Sequence
Recommended binary startup sequence:
- Start the Relay Server (
frps):
./frps -c ./frps.ini
- Start the Service Provider Client (
frpc- Private Server):
./frpc -c ./frpc_service.ini
- Start the Visitor Client (
frpc- Local PC):
./frpc -c ./frpc_visitor.ini
- Run the Local Application: Connection initiation to the local port via SSH client or browser:
8. Operational Considerations
- Strict Token Management: Since
auth.tokenand STCP’sskare stored in plain text in the configuration files, restrict the configuration file permissions appropriately (e.g.,chmod 600) and take measures to prevent accidental commits to repositories. - Connection Maintenance and Timeouts: Depending on the specifications of routers behind NAT, TCP connections may be disconnected if there is no communication for a certain period. If necessary, add keep-alive settings such as
keepalive_intervalto thefrpcconfiguration to maintain the tunnel. - Log Monitoring: In the event of connection failures, use
systemctl status frpsandsystemctl status frpcto check for authentication errors (token is invalid) or port conflicts (port already in use).