不能直接用HTTP隧道连接OceanBase，因其客户端协议为二进制长连接、非HTTP，而HTTP隧道会解析重写HTTP头并缓冲响应，破坏OB通信帧；必须使用frp等工具的TCP透传模式，配置type=tcp、正确映射端口，并调优心跳与超时参数以保障稳定性。
HTTP隧道能连上OceanBase吗？基本不能
直接用http隧道（比如ngrok、frp http模式）连接oceanbase，99%会失败。因为oceanbase客户端协议是二进制的、长连接、非http，而http隧道只转发符合http/1.1或http/2语义的流量——它会解析并重写host、connection头，甚至缓冲/分块响应，彻底破坏ob的obmysql或obproxy通信帧。
为什么frp tcp模式是唯一可行路径
必须绕过HTTP层，走纯TCP透传。OceanBase默认监听2881（MySQL协议）或2883（Oracle协议），这些端口需要被原样转发，中间不能有任何协议解析或修改。
-
frp配置里必须用[common]下的server_port+[tcp_ob]段，类型设为type = tcp，绝不能写type = http - 服务端
frps需开放对应端口（如7000），且防火墙允许入向TCP连接 - 客户端
frpc的local_port必须填OceanBase真实监听端口（比如2881），不是本地某个HTTP服务端口 - 客户端连接时，目标地址要改成
frps的公网IP +frp映射出的remote_port（例如1.2.3.4:6000），而非OceanBase本机地址
连接时遇到ERROR 1045 (28000): Access denied怎么办
这不是认证失败，而是协议错乱的典型表现：HTTP隧道强行套了HTTP壳，导致OceanBase收到畸形包，直接拒绝并返回这个MySQL通用错误码。此时检查三件事：
- 确认客户端工具（如
mysql命令、DBeaver）连的是tcp地址，不是http://开头的URL - 抓包看实际发出的是否为原始MySQL handshake包（前4字节是长度+0x00），而不是
GET / HTTP/1.1 -
obproxy日志里如果出现invalid packet header或connection reset by peer，基本可断定隧道类型选错了
性能和稳定性隐患比想象中更严重
TCP隧道本身不加密、无重试、无心跳保活。OceanBase长连接空闲超时默认是28800秒（8小时），但frp默认heartbeat_timeout仅90秒，中间NAT设备可能更早回收连接。结果就是：看似连上了，执行几条SQL后突然报Lost connection to MySQL server during query。
- 必须在
frpc配置中显式加大：heartbeat_timeout = 300，并配heartbeat_interval = 60 - 客户端连接字符串要加
connectTimeout=5000&socketTimeout=30000等参数，避免卡死 - 生产环境别依赖单点
frp——它挂了整个链路就断，且无法自动故障转移
真正难的不是打通，而是让这条TCP通道在各种NAT、运营商QoS、临时丢包下持续稳定跑满OceanBase的事务吞吐。很多团队卡在这里，反复调参却忽略底层网络不可靠这个前提。
