如何利用HTTP隧道连接ClickHouse_绕过防火墙限制技巧-navicat-PHP中文网

HTTP隧道不能直接连ClickHouse，必须通过支持HTTP CONNECT的正向代理（如Nginx）中转；ClickHouse仅响应标准HTTP请求，不解析隧道二进制流或CONNECT隧道。

HTTP隧道不能直接连ClickHouse，必须走代理中转

clickhouse原生不支持http隧道协议，它的http接口只响应标准get/post请求（如/?或/query），不解析隧道封装的二进制流或connect隧道。所以你不能像用htc/hts直连ssh或rdp那样，把clickhouse端口（默认8123）塞进http隧道里就通——它压根不认这种“套娃”流量。

真正可行的路径是：让ClickHouse继续跑在8123（或443），再用一个**支持HTTP CONNECT的正向代理**（如Nginx、Squid、Caddy）暴露在防火墙允许的80/443端口上，并配置它把CONNECT请求转发到ClickHouse服务；客户端则通过curl -x或requests.Session().proxies走该代理发起HTTPS/HTTP请求。

ClickHouse本身不处理隧道，只处理标准HTTP请求体里的SQL
所谓“HTTP隧道连ClickHouse”，本质是“HTTP代理 + ClickHouse HTTP接口”，不是隧道协议直通
如果你强行用hts -F localhost:8123 80，客户端发来的会是隧道协议头（非标准HTTP），ClickHouse直接返回400 Bad Request或静默断连

用Nginx做正向代理转发ClickHouse请求（推荐方案）

Nginx能干净地扮演“防火墙友好型入口”：监听443，校验域名或IP白名单，再把合法请求透传给内网ClickHouse的8123。它不依赖客户端装额外工具，浏览器、curl、Python脚本全都能用。

关键配置片段（/etc/nginx/conf.d/clickhouse.conf）：

upstream clickhouse_backend {
    server 127.0.0.1:8123;
}

server {
    listen 443 ssl;
    server_name ck.example.com;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    location / {
        proxy_pass http://clickhouse_backend;
        proxy_set_header Host $host;
        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;
    }
}

必须启用ssl，否则企业防火墙可能放行80但拦截无证书的443连接
proxy_pass后面不能带尾部/（即写成http://clickhouse_backend/会改写URI，导致ClickHouse找不到/路由）
别漏掉X-Forwarded-For，否则ClickHouse日志里所有IP都是127.0.0.1

客户端怎么发请求？别用curl -T，要用-X POST

很多人试过curl -x http://proxy:3128 http://ck.example.com:8123/?query=SELECT%201失败，是因为没意识到：代理模式下，URL里的host:port会被代理忽略，真正起作用的是-x指定的代理地址，以及请求头里的Host字段。

APIMart

APIMart是一款AI工具，一站式 AI API 平台，多主流模型统一访问。

下载

正确写法（以HTTPS代理为例）：

curl -x https://proxy.company.com:8080 \
     -H "Host: ck.example.com" \
     -X POST \
     --data-urlencode "query=SELECT 1" \
     https://ck.example.com/

-x指向你的公司HTTP代理（不是ClickHouse地址），且协议要匹配（https://代理需支持TLS隧道）
https://ck.example.com/只是占位URL，实际请求发给代理，由代理根据Host头转发
ClickHouse要求query参数必须用POST body提交，GET只支持极简查询（且易被WAF截断）
如果代理不支持HTTPS CONNECT（比如老旧Squid），换用http://代理+自签名证书，并加--insecure

为什么不用SOCKS5或htc/hts？因为ClickHouse不兼容

SOCKS5或htc这类工具依赖底层TCP流转发，适合Telnet、RDP、SSH等长连接协议。但ClickHouse的HTTP接口是短连接、有状态解析（依赖HTTP方法、Header、Body分界），而SOCKS5隧道只是“字节管道”，不理解HTTP语义。

用socks5://127.0.0.1:1080配Python requests，发出去的仍是标准HTTP请求，但代理层无法做Host路由或TLS卸载，容易触发403或证书错误
htc -F 8888 target:80 && curl http://localhost:8888/...看似绕开防火墙，实则多了一层无效封装，ClickHouse收到的是畸形HTTP（含隧道头）
企业级防火墙对SOCKS5 CONNECT行为越来越敏感，1080端口常被主动阻断，而443上的标准HTTPS流量几乎畅通无阻

真正卡点从来不是“能不能通”，而是“通了之后ClickHouse能不能正确解析请求”。绕过防火墙只是第一步，协议对齐才是关键。