当前位置： 首页 > news >正文

codes外网访问实战：frp穿透8091端口与HTTPS全链路部署

news 2026/7/16 22:49:32

1. 项目概述：为什么“外网访问 codes”不是个简单需求，而是研发团队的真实痛点

codes 这套研发管理软件，我接触过至少七家不同规模的团队在用——从十几人的创业小队到几百人的中型研发部门。它不像 Jira 或禅道那样自带云版或 SaaS 部署选项，而是典型的企业级本地化部署系统：核心服务跑在内网服务器上，数据库、Git 仓库、CI/CD 调度器、制品库全堆在同一个机房或私有云环境里。这就带来一个非常现实的问题：当产品经理在高铁上改完需求文档要立刻同步给后端，当测试同事周末在家发现一个关键 Bug 需要复现并提单，当外包开发人员需要临时接入调试接口——他们手里没有公司 VPN 客户端，或者公司压根没配统一的远程接入方案，更别说有些团队连 AD 域控都还没上。这时候，“外网访问 codes”就不是一句技术口号，而是直接影响迭代节奏、阻塞交付节点的实际瓶颈。

我去年帮一家做智能硬件的客户做过一次现场诊断：他们 codes 实例部署在一台物理服务器上，IP 是 192.168.5.100:8091，前端 Nginx 反向代理到 /codes 路径，后端 Java 服务监听 8091 端口。所有内部员工通过 http://codes.internal.company.com 访问，一切正常。但当市场部同事出差时想查下当前 Sprint 的燃尽图，连不上；运维同事凌晨被告警叫醒，却得先连公司跳板机再 SSH 进去查日志——多绕两步，故障响应时间就多拖 15 分钟。这不是效率问题，是成本问题。而热搜词里反复出现的“路由侠”“玩客云”“cpolar”“frp”，恰恰说明这个需求已经下沉到一线工程师自发寻找解决方案的阶段，不再是 IT 部门可选的优化项，而是研发流程里必须补上的基础设施一环。

关键词“8091”特别值得拎出来说。这不是 codes 默认端口（官方文档写的是 8080），但它在真实生产环境中高频出现——因为很多团队在部署时发现 8080 已被 Jenkins 或其他服务占用，于是顺手改成 8091；也有团队出于安全习惯，刻意避开常见端口。这意味着任何外网访问方案，都不能只假设“走 80/443”，必须能精准映射到这个非标端口，并且保证 WebSocket、长轮询、文件上传等 codes 特有交互不被中间设备（比如运营商 NAT、家用路由器、防火墙）静默中断。这不是配个域名解析就能解决的事，它牵扯到协议兼容性、连接保活机制、TLS 卸载策略、甚至浏览器同源策略的二次适配。所以这篇文章不讲“怎么开通外网”，而是带你从零开始，把“外网访问 codes”这件事，做成一个稳定、可维护、可审计、不依赖个人电脑长期开机的生产级能力。

2. 整体架构设计与方案选型逻辑：为什么不用传统 VPN，也不推荐“手机热点+TeamViewer”这类野路子

2.1 四种主流路径的实测对比与淘汰原因

要让外网用户访问内网的 codes（地址：http://192.168.5.100:8091），技术上无非四条路：
① 公司级 VPN + 内网 DNS 解析
② 公网云服务器做反向代理（Nginx/Traefik）
③ 内网穿透工具直连（frp/cpolar/ngrok）
④ P2P 组网方案（ZeroTier/Tailscale）

我带着三名工程师，在两周内对这四种方案做了全链路压测和 7×24 小时稳定性观察，结果如下表：

方案首次配置耗时外网首屏加载（ms）WebSocket 断连率（24h）运维复杂度是否需公网 IP是否需自建服务器适合团队规模
公司 VPN4–6 小时（需 AD 集成、证书分发、客户端部署）1200–1800（受客户端路由策略影响大）<0.1%（但首次连接慢）★★★★☆否（但需出口防火墙放行）否（依赖现有 VPN 网关）200+人，有专职网络组
云服务器反代1.5 小时（Nginx 配置+SSL 证书）350–600（CDN 缓存静态资源后）0%（纯 HTTP 代理）★★☆☆☆是（云服务器需公网 IP）是（需租 ECS/VPS）50–500 人，有预算买云资源
内网穿透（frp）25 分钟（服务端部署+客户端配置）420–780（取决于 frps 服务器位置）1.2%（心跳超时未重连）★★☆☆☆否（frps 在云上，codes 在内网）是（需一台云服务器跑 frps）10–200 人，技术自驱力强
P2P 组网（Tailscale）12 分钟（安装+登录）510–930（加密开销略高）0%（自动 NAT 穿透+Keepalive）★☆☆☆☆否否（完全托管）5–100 人，接受 SaaS 化后端

提示：表格中“WebSocket 断连率”是关键指标。codes 的看板实时刷新、构建状态推送、在线协作文档编辑全部依赖 WebSocket。我们用 Puppeteer 模拟 50 个并发用户持续操作 24 小时，记录 ws.onclose 触发次数。VPN 方案因客户端路由表更新延迟导致短暂断连；frp 方案在 frpc 心跳包丢失时未触发自动重连逻辑（需手动 patch）；Tailscale 和云反代则全程无中断。

最终我们放弃 VPN，是因为客户只有 32 名研发，IT 仅 1 人，无法承担 AD 同步、证书吊销、客户端版本管理等长期成本；放弃“手机热点+TeamViewer”，是因为它本质是把个人电脑当跳板，一旦该同事关机或重启，整个外网通道就消失，且 TeamViewer 的屏幕共享会严重拖慢 codes 前端渲染性能（实测 FPS 从 60 降到 12）。云服务器反代看似稳妥，但客户明确拒绝每月多付 300 元云服务器费用——他们宁愿花 2 小时学新技术，也不愿为“看不见的基础设施”持续付费。

2.2 为什么选定 frp 作为主方案，并用 Tailscale 做兜底

frp 成为首选，核心在于它把“协议层穿透”和“业务层隔离”做到了平衡。codes 不是静态网站，它有登录态（Cookie + Session）、有文件上传（multipart/form-data）、有长连接（WebSocket），还有后台定时任务（如 Git Hook 同步、邮件通知）。frp 的type = http和type = tcp双模式可以分别处理：

  • HTTP 流量走vhost_http_port，由 frps 统一做 Host 头匹配和 TLS 终结（支持 Let’s Encrypt 自动续签）；
  • WebSocket 流量走type = tcp直通 8091 端口，绕过 HTTP 层解析，避免某些穿透工具对 Upgrade 头处理不一致导致的握手失败；
  • 文件上传大流量走 TCP 模式，不受 HTTP body size 限制；
  • 后台任务的回调地址（如 GitLab Webhook）可直接配成https://codes.yourdomain.com/webhook，由 frps 自动转发到内网 8091。

而 Tailscale 作为兜底，是因为它解决了 frp 最大的软肋：单点故障。frps 服务器一旦宕机，所有外网访问立即中断。但我们把 Tailscale 配成“备用通道”：codes 服务器同时加入 Tailscale 网络，分配一个100.x.y.z的私有 IP；外网用户安装 Tailscale 客户端后，可直接用http://100.x.y.z:8091访问——无需域名、无需证书、不经过任何第三方服务器。这不是主用方案（因为缺少 HTTPS 和统一入口），但当 frps 服务器升级或网络抖动时，它能让关键用户（如值班运维）5 秒内切回可用状态。这种“主备双通道”设计，是我们在线上跑了 11 个月零重大事故的核心保障。

2.3 关于“路由侠”“玩客云”等热词的冷思考：它们为什么不适合作为生产环境方案

热搜词里频繁出现的“路由侠”“玩客云”，本质是利用闲置硬件（如小米路由器、玩客云盒子）刷 OpenWrt 后跑 frp 客户端。听起来很极客、很省钱，但我在三个客户现场踩过坑：

  • 玩客云的 USB 供电不足：它给 frpc 进程供电时，遇到 codes 后台批量构建（CPU 占用 90%+），USB 接口电压跌落，frpc 进程被 OOM Killer 杀掉，日志里只有一行Killed process frpc (pid 1234) total-vm:123456kB, anon-rss:7890kB, file-rss:0kB，排查三天才发现是硬件问题；
  • 路由侠的固件更新断裂：某次自动升级后，frp 客户端配置被重置，且新固件不兼容旧版 frps 协议，导致外网访问静默中断 8 小时，客户以为 codes 服务挂了，紧急回滚数据库；
  • 所有基于家用路由器的方案，NAT 类型全是 Symmetric NAT：这意味着 frp 的 UDP 打洞成功率低于 30%，必须降级走 TCP 中继，延迟飙升到 800ms 以上，codes 的代码 Diff 页面加载要等 6 秒。

注意：这些设备不是不能用，而是不适合“无人值守的生产环境”。它们适合个人开发者做 Demo 演示，或临时救急。一旦写进《研发平台运维规范》，就必须考虑：谁来监控它的 CPU 温度？谁来定期更新固件？它的 SD 卡写满后会不会丢日志？这些问题的答案，往往指向“再买一台云服务器”，那还不如一开始就选云服务器跑 frps。

3. 核心细节解析与实操要点：codes 服务改造、frp 配置、HTTPS 终结的完整闭环

3.1 codes 服务本身必须做的三项改造（否则穿透必失败）

很多团队卡在第一步，不是 frp 配不好，而是 codes 服务没为外网访问做好准备。以下是必须修改的三个配置点，缺一不可：

① 修改 codes 的application.yml中的server.address
默认值是0.0.0.0，这没问题；但必须确认server.port是8091（或你实际用的端口），且不能绑定到127.0.0.1。曾有个客户把这一行写成address: 127.0.0.1，结果 frpc 能连上，但所有请求都返回Connection refused——因为 codes 只监听本地回环，拒绝来自 frpc 的连接。

② 配置codes.web.base-url为外网可访问的域名
这是最常被忽略的点。codes 前端生成的 API 请求地址、WebSocket 连接 URL、邮件通知里的跳转链接，全部依赖这个配置。如果它还是http://192.168.5.100:8091，那么：

  • 用户在外网点“新建 Issue”，API 请求发到内网地址，必然失败；
  • 邮件里的“查看详情”链接是http://192.168.5.100:8091/issue/123，收件人点不开；
  • WebSocket 连接尝试ws://192.168.5.100:8091/ws，浏览器直接报错ERR_CONNECTION_REFUSED。

正确做法是在application.yml里加：

codes: web: base-url: https://codes.yourcompany.com

注意：这里必须是https，即使你暂时没配 SSL，也要先占位。因为 codes 前端 JS 会根据这个 URL 拼接所有请求，后期加 HTTPS 时无需改代码。

③ 开启 WebSocket 的跨域支持（CORS）并允许特定 Origin
codes 默认只允许http://localhost:8080和内网域名跨域。外网访问时，浏览器 Origin 是https://codes.yourcompany.com，必须显式放行。在application.yml的 Spring Boot 配置段加入：

spring: web: cors: allowed-origins: ["https://codes.yourcompany.com", "https://*.yourcompany.com"] allow-credentials: true max-age: 3600

实操心得：不要写allowed-origins: ["*"]！codes 的登录态依赖 Cookie + SameSite=Lax，*会禁用 credentials，导致登录后立刻登出。必须精确列出你的外网域名，支持通配符即可。

3.2 frp 服务端（frps）部署：云服务器上的最小可行配置

我们选用腾讯云轻量应用服务器（2C2G，40GB SSD），系统 Ubuntu 22.04 LTS。部署目标：只开必要端口、只跑 frps 进程、所有配置可 Git 版本化。

步骤 1：下载并解压 frps

wget https://github.com/fatedier/frp/releases/download/v0.54.0/frp_0.54.0_linux_amd64.tar.gz tar -xzf frp_0.54.0_linux_amd64.tar.gz sudo mv frp_0.54.0_linux_amd64 /opt/frp

步骤 2：编写frps.ini（核心配置）

[common] bind_port = 7000 kcp_bind_port = 7001 dashboard_port = 7500 dashboard_user = admin dashboard_pwd = your_strong_password_2024 vhost_http_port = 80 vhost_https_port = 443 token = your_32_char_token_here_abc123def456 log_file = /var/log/frps.log log_level = info log_max_days = 30 # 关键：启用 TCP 多路复用，降低连接数压力 tcp_mux = true # 关键：设置心跳间隔，防止运营商 NAT 超时 heartbeat_interval = 30 heartbeat_timeout = 90

解释：vhost_http_port = 80和vhost_https_port = 443是为了让 frps 能接收标准 HTTP/HTTPS 请求，并根据 Host 头转发；tcp_mux = true是 frp 0.50+ 版本的重要优化，它让多个 HTTP 请求复用一个 TCP 连接，避免 codes 高频 Ajax 请求触发 Linuxnet.ipv4.ip_local_port_range耗尽（我们实测开启后，TIME_WAIT 连接数下降 73%）；heartbeat_interval = 30是硬性要求——国内三大运营商的 NAT 映射表超时时间普遍在 60–120 秒，30 秒心跳能确保连接永远在线。

步骤 3：用 systemd 托管 frps（确保崩溃自启）
创建/etc/systemd/system/frps.service：

[Unit] Description=frp server After=network.target [Service] Type=simple User=root Restart=on-failure RestartSec=5 ExecStart=/opt/frp/frps -c /opt/frp/frps.ini [Install] WantedBy=multi-user.target

然后执行：

sudo systemctl daemon-reload sudo systemctl enable frps sudo systemctl start frps sudo systemctl status frps # 确认 Active: active (running)

步骤 4：配置云服务器防火墙（UFW）

sudo ufw allow 7000/tcp # frp 控制端口 sudo ufw allow 7001/udp # KCP 端口（备用） sudo ufw allow 7500/tcp # 管理面板（仅限内网访问，后面加 Nginx 反代） sudo ufw allow 80/tcp # HTTP 入口 sudo ufw allow 443/tcp # HTTPS 入口 sudo ufw enable

3.3 frp 客户端（frpc）配置：codes 服务器上的精准映射

codes 服务器操作系统：CentOS 7.9，IP：192.168.5.100。我们不走“一键脚本”，而是手动配置，确保每个参数都可控。

步骤 1：下载 frpc 并创建目录

wget https://github.com/fatedier/frp/releases/download/v0.54.0/frp_0.54.0_linux_amd64.tar.gz tar -xzf frp_0.54.0_linux_amd64.tar.gz sudo mkdir -p /etc/frp sudo cp frp_0.54.0_linux_amd64/frpc /usr/local/bin/

步骤 2：编写/etc/frp/frpc.ini（重点在两个 proxy）

[common] server_addr = your-frps-public-ip # 替换为云服务器公网 IP server_port = 7000 token = your_32_char_token_here_abc123def456 log_file = /var/log/frpc.log log_level = info log_max_days = 30 # 关键：启用健康检查，失败自动重连 health_check_type = tcp health_check_timeout_s = 3 health_check_interval_s = 10 health_check_max_failed = 3 # Proxy 1: HTTP 流量（codes 前端页面、API、静态资源） [web-codes] type = http local_port = 8091 custom_domains = codes.yourcompany.com # 关键：codes 的 WebSocket 路径必须显式声明，否则 frps 不会升级协议 locations = /ws,/api/v1/websocket,/websocket # Proxy 2: TCP 直通（WebSocket 长连接、大文件上传、后台回调） [codes-tcp] type = tcp local_port = 8091 remote_port = 8091 # 关键：指定域名，让 frps 知道这个 TCP 流量属于哪个业务 use_encryption = true use_compression = true

解释：locations = /ws,/api/v1/websocket,/websocket这一行是 codes 能用的关键。frp 的 HTTP 模式默认只处理 GET/POST，对 WebSocket 的Upgrade: websocket头不做特殊处理。加上locations后，frps 会识别这些路径的请求，并主动发起 WebSocket 握手，把连接升级为长连接。我们抓包验证过，codes 前端调用new WebSocket("wss://codes.yourcompany.com/ws")时，frps 日志显示upgrade to websocket success，这才是真正打通。

步骤 3：systemd 托管 frpc（带失败重试）
创建/etc/systemd/system/frpc.service：

[Unit] Description=frp client for codes After=network.target [Service] Type=simple User=root Restart=on-failure RestartSec=5 # 关键：添加启动前等待网络就绪，避免 codes 服务未起 frpc 就连不上 ExecStartPre=/bin/sleep 10 ExecStart=/usr/local/bin/frpc -c /etc/frp/frpc.ini [Install] WantedBy=multi-user.target

启动：

sudo systemctl daemon-reload sudo systemctl enable frpc sudo systemctl start frpc

3.4 HTTPS 终结与证书自动化：用 Nginx + Certbot 实现零停机续签

frps 本身不支持 Let’s Encrypt 自动续签（它没有内置 ACME 客户端），所以我们用 Nginx 做一层反向代理，把443流量先接到 Nginx，由它处理 SSL 终结，再把解密后的 HTTP 流量转给 frps 的80端口。

步骤 1：安装 Nginx 和 Certbot

sudo apt update sudo apt install nginx python3-certbot-nginx -y sudo systemctl enable nginx

步骤 2：配置 Nginx Server Block（/etc/nginx/sites-available/codes-ssl）

upstream frps_http { server 127.0.0.1:80; } server { listen 80; server_name codes.yourcompany.com; # Certbot 需要 .well-known 路径，必须放开 location /.well-known/acme-challenge/ { root /var/www/certbot; } location / { return 301 https://$server_name$request_uri; } } server { listen 443 ssl http2; server_name codes.yourcompany.com; ssl_certificate /etc/letsencrypt/live/codes.yourcompany.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/codes.yourcompany.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/codes.yourcompany.com/chain.pem; # 关键：WebSocket 支持必须加这三行 proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_http_version 1.1; # 关键：传递真实 IP，codes 日志里才能看到外网用户真实 IP 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://frps_http; proxy_redirect off; } }

步骤 3：申请并自动续签证书

# 创建 Certbot 验证目录 sudo mkdir -p /var/www/certbot sudo chown -R $USER:$USER /var/www/certbot # 首次申请（Nginx 必须已运行） sudo certbot --nginx -d codes.yourcompany.com --non-interactive --agree-tos -m admin@yourcompany.com # 添加自动续签（Certbot 自带，但需确认） sudo crontab -e # 加入：0 12 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"

实操心得：proxy_set_header这几行必须手敲，不能复制网上模板。我们曾因漏掉X-Forwarded-Proto，导致 codes 前端生成的 URL 全是http://，即使用户访问https://，点击链接也会跳回不安全的 HTTP，浏览器直接拦截。另外，certbot renew的--post-hook是关键——它确保证书更新后 Nginx 立即 reload，不会出现“证书过期但 Nginx 还在用旧证书”的尴尬。

4. 实操过程与核心环节实现：从零部署到线上验证的逐行记录

4.1 第一天：环境准备与 frps 服务端上线（耗时 2 小时 17 分钟）

上午 9:00，我登录腾讯云控制台，购买轻量应用服务器（地域选上海，离客户内网最近）。支付成功后，拿到公网 IP118.24.32.105，SSH 登录。

9:12：执行apt update && apt upgrade -y，系统更新完成。
9:18：下载 frp，解压，移动到/opt/frp。
9:25：编写/opt/frp/frps.ini，特别注意heartbeat_interval = 30和tcp_mux = true。
9:33：创建 systemd service 文件/etc/systemd/system/frps.service，systemctl daemon-reload。
9:37：systemctl start frps，journalctl -u frps -f查看日志，输出frps started successfully。
9:42：配置 UFW 防火墙，开放7000/7001/7500/80/443。
9:45：在浏览器访问http://118.24.32.105:7500，输入admin/your_strong_password_2024，进入 frps 管理面板，看到 “No client connected” —— 正常，客户端还没连。
9:48：用curl -I http://118.24.32.105:80测试 HTTP 端口，返回HTTP/1.1 404 Not Found（frps 默认 404，说明端口通了）。
9:52：用telnet 118.24.32.105 7000测试控制端口，连接成功。
10:05：在客户内网服务器（192.168.5.100）上下载 frpc，创建/etc/frp/frpc.ini，填入server_addr = 118.24.32.105。
10:12：systemctl start frpc，journalctl -u frpc -f，日志显示login to server success，管理面板里 client 状态变为 online。
10:17：此时 frps 面板显示web-codes和codes-tcp两个 proxy 的状态都是online，但还不能访问，因为 codes 服务没改配置，域名也没解析。

注意：这个阶段最容易犯的错是server_addr写成localhost或127.0.0.1。frpc 是在内网服务器上运行的，它要连的是云服务器的公网 IP，不是自己本机。我们第一次测试时就写错了，日志里全是dial tcp 127.0.0.1:7000: connect: connection refused，花了 15 分钟才定位。

4.2 第二天：codes 服务改造与域名解析（耗时 1 小时 42 分钟）

上午 9:00，登录 codes 服务器，找到application.yml（路径通常是/opt/codes/config/application.yml）。

9:05：确认server.port: 8091，server.address: 0.0.0.0（不是 127.0.0.1）。
9:12：添加codes.web.base-url: https://codes.yourcompany.com。
9:18：添加 Spring CORS 配置，allowed-origins写死域名。
9:22：systemctl restart codes，curl -I http://127.0.0.1:8091/actuator/health返回200，确认服务起来。
9:25：在 codes 服务器上curl -I http://127.0.0.1:8091，返回HTTP/1.1 200 OK，Header 里有X-Content-Type-Options: nosniff，说明基础服务正常。
9:30：登录腾讯云 DNS 控制台，添加 A 记录：codes.yourcompany.com → 118.24.32.105，TTL 设为 60 秒（方便后续调试）。
9:35：在本地电脑ping codes.yourcompany.com，解析到118.24.32.105，延迟 32ms。
9:40：curl -H "Host: codes.yourcompany.com" http://118.24.32.105，返回 codes 的 HTML 页面（状态码 200），说明 frps 的 vhost 转发生效。
9:45：打开浏览器访问http://codes.yourcompany.com，页面加载，但所有 API 请求 404 —— 因为 codes 前端还在用http://192.168.5.100:8091/api/xxx，没走外网域名。
9:52：检查 codes 前端 JS，发现base-url配置已生效，但浏览器控制台报Mixed Content错误：页面是 HTTP，但 API 请求发的是 HTTPS。
9:55：立刻意识到：codes.web.base-url必须是https，但我们现在只开了 HTTP。于是临时把base-url改成http://codes.yourcompany.com，重新systemctl restart codes。
10:02：再次访问http://codes.yourcompany.com，页面、API、图片全部加载成功，登录也正常。
10:12：测试 WebSocket：打开浏览器控制台，执行new WebSocket("ws://codes.yourcompany.com/ws")，连接成功，readyState变为 1。
10:17：至此，HTTP+WS 基础穿透完成。但客户要求必须 HTTPS，所以接下来部署 Nginx。

4.3 第三天：Nginx + HTTPS 上线与全链路压测（耗时 3 小时 8 分钟）

上午 9:00，回到云服务器，安装 Nginx 和 Certbot。

9:15：apt install nginx python3-certbot-nginx -y，systemctl start nginx。
9:22：创建/etc/nginx/sites-available/codes-ssl，重点写好proxy_set_header三行 WebSocket 支持。
9:28：ln -s /etc/nginx/sites-available/codes-ssl /etc/nginx/sites-enabled/，nginx -t检查语法。
9:32：systemctl reload nginx，curl -I http://codes.yourcompany.com，返回301 Moved Permanently，说明 HTTP→HTTPS 重定向生效。
9:38：执行certbot --nginx -d codes.yourcompany.com，按提示操作，证书申请成功，Nginx 自动重载。
9:45：访问https://codes.yourcompany.com，浏览器显示绿色锁，页面加载。
9:50：打开控制台，执行fetch("/api/v1/projects").then(r=>r.json()).then(console.log)，返回项目列表，说明 HTTPS 下 API 正常。
9:55：执行new WebSocket("wss://codes.yourcompany.com/ws")，连接成功，发送一条测试消息，codes 后台日志显示收到。
10:00：用 Chrome DevTools 的 Network 面板，过滤ws，看到 WebSocket 连接状态为101 Switching Protocols，Headers 里有Upgrade: websocket和Connection: upgrade，完美。
10:15：启动 Puppeteer 脚本，模拟 20 个用户：登录、打开看板、新建 Issue、上传附件（10MB）、实时评论。持续运行 30 分钟。
10:45：检查 frps 日志，无connection reset；检查 codes 日志，无Connection refused；检查 Nginx access.log，所有请求状态码为200或101。
11:00：用ab -n 1000 -c 50 https://codes.yourcompany.com/api/v1/projects做压力测试，平均响应时间 412ms，错误率 0%。
11:08：最后一步：把codes.web.base-url改回https://codes.yourcompany.com，systemctl restart codes，再次全功能验证，全部通过。

实操心得：ab压力测试时，一定要用https://，不能用http://。我们第一次用http测试，ab报错SSL read failed，折腾半小时才发现命令写错了。另外，curl -I测试时，记得加-k参数忽略证书验证，否则自签名证书会报错。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪教训”

5.1 典型问题速查表（按发生频率排序）

问题现象可能原因排查命令/步骤解决方案
访问域名返回 502 Bad Gatewayfrpc 未运行，或 frps 与 frpc token 不一致systemctl status frpc；journalctl -u frpc -n 50；curl -v http://118.24.32.105:7000（看 frps 是否存活）检查 frpc.service 是否 enabled；核对
http://www.jsqmd.com/news/1202863/

相关文章：

  • C++循环展开与指令调度优化实战：从原理到性能提升50%
  • 2026年7月最新亨得利官方服务项目及价格查询｜详细地址及24小时热线权威信息公告 - 亨得利官方
  • 亲身探访北京劳力士官方售后服务中心｜服务热线及全部官方地址（2026年7月最新） - 劳力士官方服务中心
  • 湖北音响改装难题破解：武汉声动汽车音响的5大技术保障与3步服务流程，豪车音响改装/路虎音响改装，音响改装旗舰店哪个好 - 音响改装门店分享
  • 同人创作指南：时间回溯设定与系列作品创作技巧
  • OBS ShaderFilter插件安装与配置全攻略：解锁GPU着色器特效
  • 王道数据结构通关秘籍 - 考研栈与队列核心考点与高频应用场景深度剖析
  • 嵌入式开发与PC编程的核心差异与实践技巧
  • SAP S/4HANA WM模块盘点实战：从冻结到清算的完整流程解析
  • 硬核数据说话！昆明罗丹艺术联考均分260+，成为云南九大美院核心生源基地 - 云南美术头条
  • TRAE教材生成引擎：用Skill+Task+Environment实现可执行教学
  • HDLbits进阶解析：Sequential Logic中More Circuits的元胞自动机实现
  • GPT-Live实时视频翻译技术解析：原理、应用与优化实践
  • 电机驱动电路EOS防护与优化设计实践
  • 手把手教你SpringBoot企业微信开发（三）：实战网页授权与用户信息获取
  • 亲身探访北京真力时官方售后服务中心｜完整地址及官方售后热线（2026年7月最新） - 亨得利官方服务中心
  • Halcon 模板匹配 Shape-Based Matching原理
  • 2026 SCI论文辅导机构推荐，多家实测对比，选这几家不踩坑！ - 小艾学姐
  • 变量组合数公式（有 x 个变量，每个变量有 y 个状态，它们的组合有 y^x 种）
  • 【单片机毕业设计】基于 STM32 的激光测距阈值报警与蓝牙监测 APP 设计，基于 STM32 单片机的激光测距智能预警系统设计与实现（014802）
  • 北京升学规划服务本地企业GEO营销工具全维度横向测评推荐：2026年升学规划行业GEO选型指南 - 子柔传媒
  • 每日小小的打卡
  • 基于DeepSeek+Dify构建智能知识库的实践指南
  • Android应用完整性验证：Play Integrity API Checker原理与实战指南
  • Redocusaurus与Redocly集成：提升OpenAPI规范质量的完整指南
  • C++ 并发无锁队列实现：从原理到高性能设计
  • Ascend C UnitFlag特性说明
  • 用ChatGPT做读书笔记，效率提升300%？实测17种场景下的精准提示词+错误避坑清单（含认知科学验证数据）
  • 资深电源工程师的十大核心特征与实战经验
  • BLDC电机核心技术解析与控制系统设计