Navicat 17 连接 ClickHouse 无新增协议支持，仍依赖 Navicat 15 起内置的 ClickHouse 驱动；连接成败取决于协议、端口、认证三要素，90% 失败源于误选 MySQL 驱动而非 ClickHouse 驱动，因二者协议不互通，服务端直接断连且无鉴权日志。
navicat 17 建立 clickhouse 连接本身没有新增连接逻辑或协议支持，它沿用的是 navicat 15 起内置的 clickhouse 驱动，不是靠“新功能”简化流程，而是靠界面交互优化——比如更清晰的驱动筛选、uri 快速粘贴、分组管理等辅助能力。真正决定能否连上的，还是协议、端口、认证这三件套。
选错驱动类型是 90% 连接失败的根源
Navicat 17 界面里“数据库类型”下拉菜单中仍存在 MySQL、PostgreSQL、ClickHouse 等选项，但用户常因惯性选 MySQL，尤其当看到“default”用户、“9000”端口时误以为兼容。ClickHouse 原生协议与 MySQL 协议完全不互通，服务端收到 MySQL 协议握手包会直接断连，日志里甚至不记鉴权失败，只留 Connection refused。
- 必须手动选
ClickHouse（不是MySQL，也不是ODBC） - 旧版 Navicat（Navicat 17 自带，无需装额外驱动或配置 DSN
- 若列表里没
ClickHouse，说明安装包是 Lite 版或未启用 Premium 模块
填 Host 和 Port 时要核对云厂商实际暴露的协议端口
云环境（阿里云 CK、ByteHouse、腾讯云 TCHouse）极少开放 9000 原生端口给公网，默认只开 8123（HTTP 接口）。但 Navicat 17 的 ClickHouse 驱动**仅支持原生协议（9000）**，不支持 HTTP 模式——这点和 DBeaver 不同。
- Host 填控制台显示的“公网地址”，不是内网域名（如
ck-xxx-public.clickhouse.aliyuncs.com） - Port 必须是
9000；若云厂商只开放8123，则此路不通，得换工具或联系厂商开通原生端口 - 填了
8123却选ClickHouse驱动 → 报Code: 210. DB::NetException: Connection refused
密码为空时，allow_empty_password 必须为 1
很多本地部署或 Docker 启动的 ClickHouse 默认用 default 用户且无密码，但 Navicat 17 会强制发送空密码字段。如果服务端 /etc/clickhouse-server/users.xml 中该用户的 <password></password> 节点存在，或 <allow_empty_password> 为 0，就会报 Code: 516. DB::Exception: default: Authentication failed。
- 检查路径：
/etc/clickhouse-server/users.xml→ 找到<user>default</user>段 - 确认含
<allow_empty_password>1</allow_empty_password> - 改完需重启服务：
sudo systemctl restart clickhouse-server
连上后表结构不显示？不是 Bug，是元数据加载策略问题
Navicat 17 对 ClickHouse 的元数据查询仍依赖 SELECT name FROM system.databases 和 SELECT * FROM system.tables，但它不会自动触发刷新。首次连接后左侧空白、双击库名报 “Database not found”，往往只是缓存没更新。
- 连接成功后，右键左侧“数据库”节点 → 点
Refresh（不是右键具体库） - Default database 字段建议留空；填了不存在的库名会导致连接建立即中断
- 如果
system库太多表卡顿，可在服务端 profile 中加<max_rows_to_read>100000</max_rows_to_read>，但这只影响后续查询，不影响 initial load
真正容易被忽略的点是：Navicat 17 的“快速连接”能力只优化了 UI 流程，没绕过 ClickHouse 的协议刚性约束。你复制一个看似正确的连接字符串，只要驱动、端口、认证三者中任一不匹配原生协议要求，就仍是白忙。
