
1. 项目概述为什么FRP至今仍是内网穿透的“稳态选择”我第一次在客户现场用FRP打通一台藏在三层NAT后面的工业PLC时是2021年冬天。那台设备连着工厂局域网再穿一层防火墙最后被运营商级NAT罩着——连ping都通不了。当时试了ngrok、cpolar、ZeroTier要么隧道建立失败要么HTTP请求超时要么HTTPS证书校验报错。直到把frp_0.54.0_windows_amd64.zip解压出来改了三行配置frpc.exe双击运行5秒后浏览器里输入http://plc-dev.yourdomain.com页面刷地一下出来了。那一刻我意识到FRP不是“又一个内网穿透工具”而是一套经过真实产线反复锤炼、能扛住复杂网络拓扑的通信协议栈。这和它底层设计直接相关。FRP不依赖P2P打洞像ZeroTier也不靠云服务中继加密流量像ngrok早期版本而是采用客户端主动注册 服务端反向代理的经典C/S模型。frpc启动后会以长连接方式持续向frps发起心跳注册服务端收到后在内存中维护一张“客户端-端口-域名-协议类型”的映射表。当外部请求到达frps监听的80/443端口时frps根据Host头或SNI信息查表把流量精准转发给对应frpc进程再由frpc通过本地回环127.0.0.1或局域网IP投递给目标服务。整个过程没有中间加密层没有TLS握手开销也没有P2P协商失败的风险——它把“稳定”二字刻进了协议基因里。这也是为什么在嵌入式、IoT、边缘计算这些对资源敏感、网络环境恶劣的场景中FRP依然被大量采用。玩客云跑frpc没问题16MB内存够用树莓派Zero W编译个armv6静态二进制就能跑甚至有人把frpc交叉编译进OpenWrt固件在路由器上常驻运行。它不追求炫酷的Web控制台不堆砌AI驱动的自动配置就老老实实做一件事让内网服务像公网服务一样被访问。你看到的“frp内网穿透”热搜背后是成千上万工程师在产线、机房、实验室里用它解决一个又一个“连不上”的具体问题。所以这篇教程不讲“FRP是什么”只讲“怎么让它在你手上真正跑起来”。我会带你从零部署一套生产可用的FRP架构覆盖Windows客户端、Linux服务端、HTTPS域名绑定、多子域名复用、以及那些只有亲手拧过螺丝才会踩到的坑——比如frpc启动后CPU飙到100%却无日志输出比如HTTP隧道能通但WebSocket连接秒断比如用Docker部署后frps无法绑定80端口却报错“address already in use”……这些都不是文档里写的“配置错误”而是网络栈、系统权限、防火墙策略、DNS解析链路共同作用的结果。接下来的内容每一行都是我在客户现场、自己服务器、测试虚拟机里一行命令一行日志验证过的实操路径。2. 整体架构设计与方案选型逻辑2.1 为什么必须分清“服务端”和“客户端”的物理边界很多新手一上来就卡在“frp到底装在哪”。他们试图在自己的笔记本上同时运行frps和frpc以为这样就能实现“本机穿透本机”。结果配置文件写完frps -c frps.ini启动成功frpc -c frpc.ini也显示“login success”但浏览器访问http://localhost:8080却打不开。问题出在架构理解上FRP的“穿透”本质是网络地址转换NAT的逆向工程它需要一个拥有公网IP的节点作为“锚点”所有内网节点通过这个锚点中转流量。如果你的笔记本没有公网IP99.9%的家庭宽带都不具备那么无论frps跑得多欢外部请求根本无法抵达它。因此标准部署必须明确两个物理角色服务端frps必须部署在拥有固定公网IP或可解析域名的服务器上。常见选择包括阿里云ECS、腾讯云CVM、Vultr VPS或者你自建的NAS需配置DDNS并开放端口。它的核心任务只有一个监听公网端口如7000用于控制信道80/443用于业务流量接收frpc注册并按规则转发。客户端frpc部署在需要被访问的内网设备上。可能是你的Windows开发机、公司内网的GitLab服务器、家里的群晖NAS、甚至一台连着4G模块的工控终端。它不暴露任何端口给外网只主动向外发起连接。这个边界一旦混淆后续所有配置都是空中楼阁。我见过最典型的错误是用户买了台云服务器装好frps后又在同台服务器上起frpc想把本机的Nginx服务“穿透”出去。这完全没必要——云服务器本身就有公网IP直接配Nginx反代即可。FRP的价值永远体现在“内网服务需要被公网访问”这个刚需上而不是给自己加一层不必要的代理。2.2 服务端部署平台选择Linux原生 vs Docker容器化服务端部署有两种主流路径我强烈建议新手从Linux原生部署开始对比维度Linux原生部署Docker容器化学习成本极低。只需下载二进制、写配置、启服务中等。需掌握docker基础命令、卷挂载、端口映射故障定位日志直出进程可见ps aux | grep frps一目了然需进入容器查日志docker logs frps进程隔离增加排查链路端口冲突直接绑定宿主机端口冲突时系统报错明确Docker网络模式复杂host模式易冲突bridge模式需额外映射长期运维systemd服务管理成熟开机自启稳定需配置docker-compose或systemd管理容器多一层抽象我坚持推荐原生部署是因为FRP服务端的核心诉求是极致稳定与最小干扰。它不需要数据库、不需要缓存、不依赖其他服务就是一个单进程监听几个端口。Docker带来的隔离性在这里是冗余的反而引入了网络命名空间、iptables规则、cgroup资源限制等新变量。去年帮一家智能硬件公司排查frps偶发中断问题最终发现是Docker daemon升级后默认启用了--iptablesfalse导致frps监听的7000端口被iptables规则拦截而日志里没有任何提示。如果是原生部署netstat -tuln \| grep :7000一眼就能看到端口是否真正在监听。当然Docker在特定场景有优势当你需要在同一台服务器上同时运行frps、Nginx、Prometheus等多个服务且希望它们的依赖环境完全隔离时或者你的运维体系已全面容器化CI/CD流水线天然支持镜像部署。但对绝大多数个人开发者和中小团队原生部署是更透明、更可控、更少意外的选择。2.3 客户端操作系统适配Windows为何要特别对待Windows客户端的部署看似简单实则暗藏玄机。最大的差异在于网络栈行为和权限模型网络栈Windows的TCP KeepAlive默认时间远长于Linux2小时 vs 7200秒导致frpc与frps的长连接在空闲时更容易被中间防火墙尤其是企业级NGFW主动切断。解决方案不是调大KeepAlive而是让frpc主动发送心跳包这需要在frpc.ini中显式配置heartbeat_interval 30单位秒。权限模型Windows服务默认以LocalSystem身份运行但frpc若以服务形式安装其访问本地服务如http://127.0.0.1:3000时可能因UAC或服务会话隔离Session 0 Isolation导致连接被拒绝。最稳妥的方式是让frpc以当前用户身份运行即双击frpc.exe或用start /b frpc.exe -c frpc.ini确保它和你的开发服务处于同一会话上下文。另一个常被忽略的点是防病毒软件拦截。国内某知名安全软件会将frpc.exe识别为“可疑网络行为程序”静默阻止其建立外网连接。这不是FRP的问题而是Windows生态的现实。解决方案很简单在安全软件设置中将frpc.exe所在目录加入白名单或临时禁用实时防护进行测试。这个细节在Linux世界不存在却是Windows用户踩坑率最高的环节之一。3. 核心细节解析与实操要点3.1 服务端frps部署从下载到开机自启的完整闭环第一步永远是获取官方二进制。不要用第三方打包的“一键脚本”也不要从GitHub Release页面随便点最新版。FRP的版本迭代很快但并非所有新版都经过充分验证。我的经验是生产环境锁定LTS版本如v0.54.0测试环境可用最新稳定版但务必跳过带rcRelease Candidate标识的版本。访问https://github.com/fatedier/frp/releases找到frp_0.54.0_linux_amd64.tar.gz根据你的服务器CPU架构选择ARM64选frp_0.54.0_linux_arm64.tar.gz用wget下载wget https://github.com/fatedier/frp/releases/download/v0.54.0/frp_0.54.0_linux_amd64.tar.gz tar -zxvf frp_0.54.0_linux_amd64.tar.gz cd frp_0.54.0_linux_amd64解压后你会看到一堆文件其中frps是服务端主程序frps_full.ini是完整配置示例frps.ini是精简模板。我们不直接修改模板而是新建一个/etc/frp/frps.ini[common] bind_port 7000 kcp_bind_port 7001 dashboard_port 7500 dashboard_user admin dashboard_pwd your_strong_password_here vhost_http_port 80 vhost_https_port 443 token your_very_secret_token_here这里每个参数都有明确目的bind_port 7000frpc用来注册和维持心跳的TCP端口必须开放给外网云服务器安全组需放行。kcp_bind_port 7001KCP协议端口用于在高丢包网络如跨国链路下提升传输效率。如果你的frpc和frps之间网络质量差开启它并让frpc配置protocol kcp能显著降低延迟抖动。dashboard_port 7500内置Web监控面板端口可通过http://your-server-ip:7500查看隧道状态、流量统计。dashboard_user/pwd是登录凭证必须修改否则等于裸奔。vhost_http_port 80和vhost_https_port 443这是关键它们让frps能像Nginx一样根据HTTP Host头分发请求。例如a.example.com走A隧道b.example.com走B隧道全靠这两个端口接收并解析。tokenfrpc连接frps时必须提供的密钥防止未授权客户端接入。长度建议16位以上含大小写字母数字。配置写完先手动测试启动./frps -c /etc/frp/frps.ini如果看到frps start success且netstat -tuln | grep :7000显示LISTEN说明基础服务已就绪。此时用浏览器访问http://your-server-ip:7500输入账号密码应该能看到空的隧道列表。接下来是生产环境必备的开机自启。别用nohup ./frps ... 这种野路子要用systemd标准化管理。创建/etc/systemd/system/frps.service[Unit] DescriptionFRP Server Service Afternetwork.target [Service] Typesimple Userroot Restarton-failure RestartSec5 ExecStart/usr/local/bin/frps -c /etc/frp/frps.ini ExecReload/bin/kill -15 $MAINPID KillModeprocess [Install] WantedBymulti-user.target注意三点Userroot确保有权限绑定80/443等特权端口Linux规定1024以下端口需root权限。Restarton-failurefrps崩溃后自动重启避免服务中断。ExecStart路径指向/usr/local/bin/frps所以需要把二进制文件复制过去sudo cp frps /usr/local/bin/ sudo systemctl daemon-reload sudo systemctl enable frps sudo systemctl start frps执行完sudo systemctl status frps应显示active (running)。这才是一个生产就绪的服务端。3.2 客户端frpcWindows部署规避UAC与杀软的实战技巧Windows部署的核心矛盾在于既要保证frpc能稳定运行又要让它能无障碍访问本地服务。很多教程教你在PowerShell里执行.\frpc.exe -c frpc.ini这在管理员权限下能跑但一旦关闭终端进程就退出。而做成Windows服务又可能因Session 0隔离无法访问127.0.0.1上的开发服务。我的方案是用Windows任务计划程序Task Scheduler实现“用户登录时启动”“保持后台运行”。它比服务更轻量且天然运行在用户会话中。首先下载Windows客户端。同样去GitHub Releases找frp_0.54.0_windows_amd64.zipWin10/11 64位或frp_0.54.0_windows_386.zip32位系统。解压到一个固定路径比如C:\frp\。然后创建C:\frp\frpc.ini[common] server_addr your-frps-server-ip-or-domain.com server_port 7000 token your_very_secret_token_here heartbeat_interval 30 heartbeat_timeout 90 [web] type http local_port 3000 custom_domains dev.yourdomain.com关键参数解读server_addr填你frps服务器的公网IP或域名。强烈建议用域名因为IP可能变更而域名可通过DNS快速切换。heartbeat_interval 30如前所述主动发送心跳防止中间防火墙断连。[web]段定义一个HTTP隧道把本地3000端口假设你本地起了一个Vue Dev Server映射到dev.yourdomain.com。现在创建任务计划打开“任务计划程序”点击“创建基本任务”。名称填FRP Client Auto Start描述可选。触发器选“当用户登录时”。操作选“启动程序”程序路径填C:\frp\frpc.exe参数填-c C:\frp\frpc.ini起始于填C:\frp\。最后一步勾选“打开属性对话框”在“常规”选项卡中勾选“不管用户是否登录都要运行”和“不存储密码”这样任务会以最高权限运行但不会弹UAC。提示如果勾选“不存储密码”任务将以SYSTEM账户运行此时local_port必须是frpc能访问的服务。对于127.0.0.1:3000只要你的开发服务也是以当前用户启动如VS Code终端里npm run serve就完全没问题。这是平衡稳定性与兼容性的最优解。防病毒软件拦截是另一道坎。以Windows Defender为例它有时会把frpc标记为“潜在不需要的应用”PUA。解决方法打开“Windows安全中心” → “病毒和威胁防护” → “管理设置” → “添加或删除排除项” → “添加一个排除项” → 选择C:\frp\文件夹。或者在PowerShell中以管理员身份运行Add-MpPreference -ExclusionPath C:\frp\做完这两步注销再登录打开任务管理器你应该能在“后台进程”里看到frpc.exe且CPU占用稳定在0.1%左右。此时在浏览器访问http://dev.yourdomain.com就能看到本地3000端口的服务了。3.3 HTTPS隧道配置Lets Encrypt自动化与Nginx共存方案很多教程止步于HTTP隧道但生产环境必须HTTPS。FRP本身不提供SSL证书它依赖frps监听的443端口来终结TLS。这意味着你需要在frps服务器上为dev.yourdomain.com这个域名配置有效的HTTPS证书。最优雅的方案是让Nginx作为frps的前置反向代理由Nginx处理HTTPS终结再把解密后的HTTP流量转发给frps的vhost_http_port即80端口。这样做的好处是Nginx可以集中管理所有域名的证书用certbot自动续期。frps专注做隧道转发不耦合证书逻辑。后续想给某个隧道加WAF、限流、日志分析都在Nginx层统一配置。假设你的frps已运行vhost_http_port 8080为避免和Nginx冲突我们把它改成8080vhost_https_port 443保留。Nginx配置/etc/nginx/conf.d/frp.conf如下upstream frp_backend { server 127.0.0.1:8080; } server { listen 80; server_name dev.yourdomain.com test.yourdomain.com; # HTTP重定向到HTTPS return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name dev.yourdomain.com test.yourdomain.com; ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # FRP要求的Header透传 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; location / { proxy_pass http://frp_backend; proxy_redirect off; } }关键点upstream frp_backend指向frps的vhost_http_port8080而非7000那是控制端口。proxy_set_header系列确保frps能正确读取原始Host和IP这对custom_domains匹配至关重要。ssl_certificate路径由certbot生成用sudo certbot --nginx -d dev.yourdomain.com -d test.yourdomain.com一键申请。配置完成后sudo nginx -t sudo systemctl reload nginx。此时frps的vhost_http_port8080只接受来自本机Nginx的流量外部HTTPS请求全部由Nginx处理。你的frpc配置无需改动custom_domains依然填dev.yourdomain.comfrps会根据Host头准确路由。注意如果frps和Nginx都试图监听443必然端口冲突。所以必须让frps退守到非特权端口如8080把443留给Nginx。这是生产环境的标准分工。4. 实操过程与核心环节实现4.1 从零开始的全流程部署一次成功的完整记录现在让我们把前面所有知识点串起来走一遍从服务器初始化到隧道可用的完整流程。以下是我上周在一台全新的腾讯云CentOS 7.9服务器上为客户的React前端项目部署FRP的真实操作记录已脱敏。Step 1服务器初始化# 更新系统 sudo yum update -y # 关闭SELinux避免权限干扰 sudo sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config sudo setenforce 0 # 开放必要端口云服务器安全组也要同步配置 sudo firewall-cmd --permanent --add-port7000/tcp sudo firewall-cmd --permanent --add-port7500/tcp sudo firewall-cmd --permanent --add-port8080/tcp # frps的vhost_http_port sudo firewall-cmd --reloadStep 2部署frps# 下载并解压 cd /tmp wget https://github.com/fatedier/frp/releases/download/v0.54.0/frp_0.54.0_linux_amd64.tar.gz tar -zxvf frp_0.54.0_linux_amd64.tar.gz sudo mkdir -p /etc/frp sudo cp frp_0.54.0_linux_amd64/frps /usr/local/bin/ sudo cp frp_0.54.0_linux_amd64/frps_full.ini /etc/frp/frps.ini # 编辑配置关键部分 sudo vim /etc/frp/frps.ini # [common]段修改为 bind_port 7000 kcp_bind_port 7001 dashboard_port 7500 dashboard_user frpadmin dashboard_pwd Frp2024Secure! vhost_http_port 8080 vhost_https_port 443 token A1b2C3d4E5f6G7h8Step 3配置systemd服务sudo tee /etc/systemd/system/frps.service /dev/null EOF [Unit] DescriptionFRP Server Service Afternetwork.target [Service] Typesimple Userroot Restarton-failure RestartSec5 ExecStart/usr/local/bin/frps -c /etc/frp/frps.ini ExecReload/bin/kill -15 $MAINPID KillModeprocess [Install] WantedBymulti-user.target EOF sudo systemctl daemon-reload sudo systemctl enable frps sudo systemctl start frps sudo systemctl status frps # 确认active (running)Step 4配置Nginx与HTTPS# 安装Nginx sudo yum install epel-release -y sudo yum install nginx -y sudo systemctl enable nginx sudo systemctl start nginx # 安装certbot sudo yum install certbot python3-certbot-nginx -y # 申请证书先确保DNS已解析到此服务器IP sudo certbot --nginx -d frontend.devops-company.com # 创建FRP专用Nginx配置 sudo tee /etc/nginx/conf.d/frp.conf /dev/null EOF upstream frp_backend { server 127.0.0.1:8080; } server { listen 80; server_name frontend.devops-company.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name frontend.devops-company.com; ssl_certificate /etc/letsencrypt/live/frontend.devops-company.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/frontend.devops-company.com/privkey.pem; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; location / { proxy_pass http://frp_backend; proxy_redirect off; } } EOF sudo nginx -t sudo systemctl reload nginxStep 5Windows客户端配置与启动在开发机上解压frp_0.54.0_windows_amd64.zip到C:\frp\。创建C:\frp\frpc.ini[common] server_addr frp.devops-company.com # CNAME指向云服务器IP server_port 7000 token A1b2C3d4E5f6G7h8 heartbeat_interval 30 heartbeat_timeout 90 [react-dev] type http local_port 3000 custom_domains frontend.devops-company.com用任务计划程序创建开机启动任务如前文所述。Step 6验证与调试访问https://frontend.devops-company.com应看到本地3000端口的React应用。访问http://frp.devops-company.com:7500登录后看到react-dev隧道状态为online流量计数开始增长。在Windows上打开命令提示符执行netstat -ano | findstr :3000确认npm start进程在监听。在服务器上执行sudo ss -tuln | grep :7000确认frps在监听。整个过程耗时约25分钟其中80%时间花在DNS解析生效TTL等待和certbot交互上。一旦配置完成这套架构可以稳定运行数月无需干预。4.2 多隧道复用与子域名规划一个frps服务支撑多个项目一个frps实例完全可以承载多个独立项目关键在于子域名规划和隧道隔离。假设你有三个项目前端frontend.devops-company.com→ 本地3000端口后端APIapi.devops-company.com→ 本地8000端口文档站docs.devops-company.com→ 本地8080端口只需在frps配置中保持vhost_http_port 8080不变然后在frpc端为每个项目创建独立的隧道段[common] server_addr frp.devops-company.com server_port 7000 token A1b2C3d4E5f6G7h8 heartbeat_interval 30 [frontend] type http local_port 3000 custom_domains frontend.devops-company.com [backend-api] type http local_port 8000 custom_domains api.devops-company.com [docs-site] type http local_port 8080 custom_domains docs.devops-company.comNginx配置无需改动因为它把所有*.devops-company.com的HTTPS请求都转发给了frps的8080端口。frps内部会根据HTTP Host头frontend.devops-company.com、api.devops-company.com自动匹配到对应的隧道段再把流量导向不同的local_port。这种设计的优势是极致的解耦前端团队只需关心frontend.devops-company.com不用知道后端API的端口。运维只需维护一个frps实例和一个Nginx配置新增项目只需在frpc端加一段配置。每个隧道的健康状态、流量、连接数在Dashboard里独立显示便于监控。实操心得子域名必须提前在DNS服务商处配置CNAME记录指向你的frps服务器域名如frp.devops-company.com。不要用A记录直接指向IP因为IP可能变更。CNAME可以随时切换且支持泛解析*.devops-company.comCNAME tofrp.devops-company.com为未来扩展留足空间。5. 常见问题与排查技巧实录5.1 “Login failed: authorization failed” —— token不匹配的终极排查法这是新手遇到的第一道墙。错误日志就这一行但原因可能有五种。我整理了一个速查表按发生概率排序可能原因排查命令/步骤解决方案frpc.ini中的token与frps.ini不一致在服务器上执行sudo grep token /etc/frp/frps.ini在Windows上用记事本打开C:\frp\frpc.ini对比严格复制粘贴注意空格和大小写。建议用密码管理器生成并同步。frps服务未重启配置未生效sudo systemctl status frps查看启动时间sudo journalctl -u frps -n 20查看最近日志sudo systemctl restart frps确认日志显示frps start success。frpc连接的是旧IP或域名DNS未更新在Windows命令提示符执行nslookup frp.devops-company.com确认解析到正确的服务器IP清理本地DNS缓存ipconfig /flushdns检查hosts文件是否有旧记录。云服务器安全组未放行7000端口登录云厂商控制台检查安全组入方向规则添加规则端口7000协议TCP源IP0.0.0.0/0或限制为你的办公IP段。frps进程被其他程序占用7000端口sudo ss -tuln | grep :7000如果显示LISTEN但不是frps则被占sudo lsof -i :7000查进程sudo kill -9 PID杀掉再启frps。最隐蔽的一种情况frps配置文件中有BOM头。Windows记事本保存的UTF-8文件默认带BOMLinux下的frps读取时会把BOM当作token的一部分导致校验失败。解决方案用VS Code打开frps.ini右下角点击编码如“UTF-8 with BOM”选择“Save with Encoding” → “UTF-8”。5.2 “Connection refused” —— 本地服务不可达的深度诊断当frpc日志显示[W] [service.go:104] login to server failed: dial tcp 127.0.0.1:3000: connect: connection refused说明frpc无法连接到你指定的local_port。这不是FRP的问题而是本地服务没起来或端口被占。标准诊断流程确认服务进程存在在Windows上netstat -ano | findstr :3000。如果有输出记下PID再用tasklist | findstr PID看进程名。如果没有输出说明服务根本没监听3000端口。检查服务绑定地址很多开发服务如Vue CLI默认只绑定127.0.0.1这没问题但有些服务如某些Java应用默认绑定0.0.0.0这也没问题。真正的问题是服务是否在frpc所在的用户会话中启动如果你用管理员PowerShell启动了npm run serve而frpc是用任务计划以SYSTEM账户运行它们不在同一会话127.0.0.1对SYSTEM来说是另一个网络栈。解决方案统一用当前用户启动服务或改用localhostWindows下localhost和127.0.0.1行为一致。检查防火墙Windows Defender防火墙可能阻止了127.0.0.1的回环连接。临时关闭防火墙测试netsh advfirewall set allprofiles state off。如果此时frpc连上了说明是防火墙规则问题需在高级防火墙中为frpc.exe添加入站规则。踩坑实录曾有一个客户他的Electron应用在127.0.0.1:8080提供API但frpc死活连不上。最后发现该应用有个“仅允许本地连接”的安全选项默认开启它会拒绝所有来自127.0.0.1的连接包括frpc。关闭此选项后立即正常。这提醒我们永远假设本地服务有自己的安全策略FRP只是流量管道不解决服务自身的访问控制问题。5.3 Dashboard打不开或显示空白端口、权限与CORS的三角困局http://your-server-ip:7500打不开或打开后一片空白通常不是frps没启动而是被三重屏障挡住第一重端口未开放云服务器安全组确认7500端口已放行。本地防火墙sudo firewall-cmd --list-ports查看若无7500执行sudo firewall-cmd --permanent --add-port7500/tcp sudo firewall-cmd --reload。第二重Dashboard绑定地址错误frps默认只绑定0.0.0.0:7500但某些定制版内核或特殊网络环境可能受限。在frps.ini中显式指定[common] dashboard_addr 0.0.0.0 dashboard_port 7500dashboard_addr 0.0.0.0强制监听所有网卡而非默认的127.0.0.1。第三重浏览器CORS阻止最隐蔽Dashboard前端资源JS/CSS由frps内置HTTP服务提供。如果frps服务器的hostname和你访问的URL不一致如服务器hostname是iZxxx你却用http://1.2.3.4:7500访问现代浏览器会因CORS策略阻止