来源：intranet-tunnel/docs/AGENTS-ARCHIVE.md → ### ⚠️ 排障时容易自设陷阱的两个点（原文 670 字符）

⚠️ 排障时容易自设陷阱的两个点

1. curl --resolve <域名>:443:127.0.0.1 会得到误导结果。

本机测隧道域名时要解析到公网 IP（<公网IP>）， 指到 127.0.0.1 会绕过公网入口的 SNI 处理，实测返回 404，让人误判配置没生效。

1. DNS 缓存会造成「刚加的记录不生效」的假象。

实测 *.tunnel 记录加好后，本机仍解析到旧的阿里云 IP， 于是 curl 拿到了 all.sushike.cloud.a1.initaf.com 的企业站内容（200 + HubSpot CSP）， 一度误以为是 nginx 路由错了。等缓存过期或换 --resolve 强制解析再测。

1. Portainer CE 的响应头容易认错：它自带

Content-Security-Policy: ... js.hsforms.net ... recaptcha ...、 Permissions-Policy: accelerometer=(), ...、X-Csrf-Token， 看起来像某个企业站。认隧道是否生效要看 X-Proxy-By: intranet-tunnel 头 （内置反代添加的），或看 HTML 里的 ng-app="portainer" / <title>Portainer</title>。

---

来源：intranet-tunnel/docs/AGENTS-ARCHIVE.md → ### ⚠️ 已知缺陷：隧道变更后反代规则不会自动更新（原文 561 字符）

⚠️ 已知缺陷：隧道变更后反代规则不会自动更新

proxy.Manager 提供了 EnsureTunnelRule / RemoveTunnelRule， 但全项目没有任何调用点（control 包不引用 proxy）。后果：

• 客户端上线新建隧道、或在面板新增/修改隧道后，内置反代不会装载对应规则，

访问域名得到 404「没有匹配的反向代理规则」（该 404 页面来自项目内置反代，不是 nginx）。

• 启动服务端时会 reload 并打印

反向代理规则已重载 rules=0 tunnel_rules=N —— 这一行是判断规则是否装载的关键日志。

当前 workaround：改完隧道后调用 POST /api/proxies/reload（面板的"重载反向代理"）， 或 docker compose restart tunnel-server。

根治方向：在 control 包拿到 proxy.Manager 引用，于隧道增删改处调用 EnsureTunnelRule / RemoveTunnelRule，并在 ensureStaticTunnels 落库后触发一次。