frp 作为内网穿透工具，部署到公网服务器后，等于在公网和内网之间开了一扇门。门打开以后，如果连身份校验都没有，任何扫描到 7000 端口的人都可以尝试建立连接。这意味着攻击者可能利用你的服务器访问公司内网、家庭 NAS 或本地开发环境。安全配置不是等被入侵后再补救，而是第一次启动 frps 之前就应该完成的步骤。
认证与加密：先堵住未授权连接
frps 默认允许任意 frpc 客户端注册代理，这种开放性在内网测试时方便，放到公网上非常危险。第一层防护是配置 token。frps 和 frpc 两端必须使用完全相同的随机字符串，握手时才会互相校验。token 不建议使用短单词或常见组合，最好用足够长的随机值。
下面是一个基础 frps 配置，所有涉及认证的地方都建议替换成自己的随机内容：
# frps.ini 服务端配置 [common] bind_port = 7000 token = 9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c dashboard_port = 7500 dashboard_user = frpadmin dashboard_pwd = Qw9Lp2Xc7Vb5Nk8 allow_ports = 2000-3000,4000
对应的 frpc 配置里，token 必须与 frps 完全一致。如果两端 token 不匹配，日志会提示认证失败，frpc 无法完成注册。除了 token，还建议开启 TLS。TLS 是在传输层对控制连接和代理流量做加密，避免 token 和代理数据在公网明文传输。开启 TLS 需要准备证书文件，配置如下：
[common] bind_port = 7000 token = 9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c # 开启TLS传输加密 tls_enable = true tls_cert_file = /etc/frp/server.crt tls_key_file = /etc/frp/server.key
证书可以用自签名证书，也可以使用公网域名申请免费证书。自签名证书虽然加密能力不差，但客户端需要相应地正确配置。无论选哪种，TLS 都能显著提高中间人攻击的门槛。
端口策略与访问控制：只开放必要端口
frp 的端口分两类：一类是 frps 自身服务端口，例如 bind_port 和 dashboard_port；另一类是实际代理业务端口，例如远程访问 SSH 或 Web 服务时使用的端口。攻击面主要来自边界上的开放端口，因此端口不能无脑全开。
在 frps 配置里，allow_ports 可以限制 frpc 能够申请的远程端口范围。比如只允许使用 2000 到 3000 这段端口和一个固定端口 4000，其他端口一律拒绝。这样做能防止客户端被入侵后随意开放高位端口绕过安全设备。
同时还要在系统防火墙或云安全组上做来源限制。如果只有固定办公出口 IP 或固定家庭宽带 IP 需要连接 frps，就应该把 7000 端口只对该 IP 开放：
# 仅允许来自 203.0.113.10 的客户端访问 frps 服务端口 iptables -A INPUT -p tcp --dport 7000 -s 203.0.113.10 -j ACCEPT iptables -A INPUT -p tcp --dport 7000 -j DROP # 仪表盘端口只允许本机访问 iptables -A INPUT -p tcp --dport 7500 -s 127.0.0.1 -j ACCEPT iptables -A INPUT -p tcp --dport 7500 -j DROP
云服务器还要检查安全组规则，安全组相当于云平台外层防火墙。即使系统内 iptables 配置正确，安全组默认放行也会带来额外风险。业务端口同样按需开放，不要为了方便直接放行 1-65535 这种宽泛范围。
仪表盘和运行账户：降低被爆破后的风险
frps 提供的 Web 仪表盘可以查看在线连接、代理状态和流量信息，但如果仪表盘暴露公网并且使用弱密码，就等于把内网穿透拓扑直接送给攻击者。仪表盘端口建议只对本地或跳板机开放，无法本地访问时可以配合 SSH 隧道访问。
仪表盘用户名和密码要单独设置，不要沿用默认的 admin 和 admin。强密码长度建议 12 位以上，包含大小写字母和数字。尽管 frp 的仪表盘本身有登录机制，强密码仍然是防止暴力破解的基础。
另一个容易忽略的细节是运行账户。很多人为了方便直接用 root 启动 frps，一旦服务本身出现漏洞或被恶意配置，攻击者就可能获得 root 权限。更好的做法是创建独立系统账户，并让 systemd 以该账户运行：
[Unit] Description=FRP Server After=network.target [Service] User=frp Group=frp ExecStart=/usr/local/bin/frps -c /etc/frp/frps.ini Restart=on-failure [Install] WantedBy=multi-user.target
同时可以设置 NoNewPrivileges=true、ProtectSystem=full 等 systemd 加固选项，进一步限制进程权限。日志也要定期查看，例如用 journalctl -u frps -f 观察实时连接，出现陌生 IP 频繁认证失败时及时调整防火墙策略。
常见疑问与排错：少走弯路
第一个常见问题是 frpc 连不上 frps。排查时先看两端 token 是否完全一致，再看服务器防火墙和云安全组是否放行了 bind_port。如果使用域名连接，还要确认域名解析和 CDN 是否支持 TCP 代理。
第二个常见误解是以为换个高端口就能高枕无忧。换端口确实能减少一部分无差别扫描，但不能替代 token、TLS 和访问控制。攻击者如果针对你的服务器做端口扫描，仍然能够发现 frps 服务。安全必须依赖认证和最小权限，而不是依赖端口隐蔽。
第三个疑问是 Docker 部署是否更安全。Docker 只是改变了部署方式，容器映射到宿主机端口后，暴露面与直接部署没有本质区别。容器内 frps 的 token、端口范围和运行账户策略仍然需要配置。不要把安全寄托在容器隔离上。
按照认证、加密、端口控制、仪表盘权限、运行账户这个顺序检查，基本可以覆盖 FRP 服务器从上线到日常运行的主要风险点。上线前把默认配置改掉，再用防火墙限制来源，能避免大多数因为内网穿透引发的安全事故。