navicat中http隧道是每个连接独占的，需各自上传tunnel.php并填相同参数；脚本须部署在可公开访问的web服务器上，且php支持sockets、allow_url_fopen开启，目标主机必须填内网数据库ip而非localhost。
navicat 中根本不存在“团队公用的 http 隧道”——http 隧道配置是每个连接独占、不可复用、无法导出为独立服务的。所谓“公用”，只是多个成员各自上传同一份 tunnel.php、填同一组参数，而非共享一条真实隧道链路。
tunnel.php 必须部署在每个成员都能访问的 Web 服务器上
这不是 Navicat 的功能限制，而是 HTTP 隧道协议本身的运行逻辑：tunnel.php 是一个 PHP 脚本，它在 Web 服务器上以 CGI 模式执行，负责接收 Navicat 发来的 TCP 封装请求，并转发到内网数据库（如 MySQL 的 192.168.1.100:3306）。
- 每个团队成员必须能通过浏览器直接访问该脚本 URL，例如
@#@#@#@#@#@#@#@#@#@0 - 返回应为纯文本（如
OK）或空响应；若返回 PHP 错误、404、下载弹窗，说明脚本未正确运行 - 脚本不能放在有
.htaccess拒绝执行的目录（如/admin/）、不能被 PHP 禁用函数拦截（fsockopen、sockets_create必须可用）
常见失败点：
-
allow_url_fopen = Off或extension=sockets未启用（Linux 下常需手动打开） - Web 服务器 PHP 版本低于 5.6（Navicat 15 官方最低要求）
-
tunnel.php权限不是644，或所在目录不可读
Navicat 连接中「HTTP 隧道」设置只在「SSH」标签页里找
很多人翻遍「常规」「高级」「SSL」都找不到入口，是因为 Navicat 把 HTTP 隧道和 SSH 隧道混放在同一个界面：
- 进入连接设置 → 切换到「SSH」标签页
- 在左下角勾选「使用 HTTP 隧道」（不是「使用 SSH 隧道」）
- 「HTTP 隧道 URL」填完整地址，带协议、不加尾部斜杠：
@#@#@#@#@#@#@#@#@#@0 - 「目标主机」填内网数据库 IP（如
192.168.1.100），不能写localhost或127.0.0.1（那是 Web 服务器本机） - 「目标端口」填数据库实际监听端口（如
3306） - 「用户名」和「密码」是数据库账号，Navicat 不会把它们发给
tunnel.php，脚本里已固化认证逻辑
注意：Navicat 不校验这些参数是否真实可达，只负责封装并 POST 请求过去。连不上时，先手动 curl 测试脚本是否存活。
团队成员必须统一确认三件事，否则 90% 连接失败
很多团队把 tunnel.php 一传了事，结果每人报错各不同，根源都在这三点没对齐：
-
tunnel.php里硬编码的数据库地址是否一致？比如有人改成了10.0.2.5，有人还留着192.168.1.100 - Web 服务器是否允许从脚本发起外连？执行
php -r "var_dump(fsockopen('192.168.1.100', 3306, $e, $s, 3));"应返回 resource - 数据库是否允许该内网 IP 的连接？MySQL 中执行：
SELECT host FROM mysql.user WHERE user='your_user';，结果里必须含192.168.1.100（即 Web 服务器 IP），不是%或localhost
别忽略 DNS 解析问题：tunnel.php 若用域名连数据库（如 db.internal），而 Web 服务器没配好 /etc/hosts 或 DNS，就会静默超时。
HTTP 隧道本质是“Web 服务器当 TCP 中继”，它不加密、不保活、不重连，一旦脚本进程崩溃或 PHP 超时，Navicat 就立刻断开且无提示。生产环境慎用，尤其当 tunnel.php 部署在共享虚拟主机或资源受限的云函数上时，稳定性远不如 SSH 隧道。
