SQL Server 原生不支持 HTTP 协议，客户端必须通过 TCP（默认1433端口）连接；HTTP 隧道需第三方代理伪装流量，并非其自身功能。
SQL Server 连接被防火墙拦截时，HTTP 隧道不是标准解法
直接说结论：sql server 原生不支持 http 协议通信，sqlcmd、ssms 或 pyodbc 等客户端一律走 tcp（默认端口 1433），强行套 http 隧道需依赖第三方代理层，本质是“把 tcp 流量伪装成 http 请求”，不是 sql server 自身功能。
用 ngrok 或 cloudflared 做反向隧道前，先确认权限和网络拓扑
这类工具能绕过出口防火墙（比如公司只放行 80/443），但前提是：你能在 SQL Server 所在机器上执行命令并出网。常见失败点不是配置错，而是权限卡死：
-
ngrok需要本地有管理员权限启动服务，并监听127.0.0.1:1433—— 但 SQL Server 默认不接受localhost以外的连接，得先改SQL Server Configuration Manager里的TCP/IP协议状态为启用，且确认IPAll下的TCP Port是明确数字（非0） -
cloudflared的tunnel模式不支持纯 TCP 转发（v2023+ 才加了--tcp实验性支持），误用--url http://127.0.0.1:1433会直接报错unsupported scheme "http" - 即使隧道建好，客户端连接字符串里必须写隧道提供的公网地址（如
xxx.ngrok-free.app），且端口是443或80；SQL Server 不会自动把443映射回本地1433，这层映射由隧道工具完成
pyodbc 连接串里不能写 http://，但得配合隧道工具改目标地址
错误示范："DRIVER={ODBC Driver 17 for SQL Server};SERVER=http://tunnel.example.com;PORT=443;..." —— pyodbc 会直接报 Unable to complete login process due to missing server name，因为它根本不解析 http:// 前缀。
正确做法是把隧道地址当普通主机名用：
- 假设
ngrok tcp 1433返回0.tcp.au.ngrok.io:12345，连接串就写SERVER=0.tcp.au.ngrok.io;PORT=12345; - 若用
cloudflared tunnel --tcp 1433，它会生成类似tcp://my-sql-tunnel.trycloudflare.com:22222的地址，去掉tcp://和端口后缀，实际填的是my-sql-tunnel.trycloudflare.com和22222 - 务必关闭
Encrypt=yes（除非你给隧道加了 TLS 终止），否则 SQL Server 客户端会尝试协商加密，而中间隧道只是透传字节流，握手直接失败
生产环境别用 HTTP 隧道连 SQL Server，延迟和稳定性太不可控
真实场景下，ngrok 免费版带宽限速、连接随机断开；cloudflared 的 TCP 隧道没有重连保活机制，一次网络抖动就导致 pyodbc 报 Adaptive Server connection failed。更麻烦的是：SQL Server 的登录超时默认 15 秒，而隧道首次建立可能耗时 8–10 秒，容易触发误判。
真正该优先检查的，是能否调整防火墙策略本身——比如申请开通 1433 端口白名单，或改用 Windows 身份验证 + 域内 Kerberos 转发，而不是在传输层硬套一层 HTTP 包装。
