DataStax驱动连接Cassandra报‘All host(s) tried for query failed’：为何TablePlus禁用SSL可连接而驱动不行？

咱们先把核心差异点说透：TablePlus这类GUI客户端选“SSL Disabled”时，是直接跳过所有SSL握手逻辑，直奔非SSL端口连接；但DataStax驱动的默认行为和这个不一样——哪怕你没主动开SSL，部分版本的驱动仍会默认尝试SSL连接，或者必须显式配置禁用SSL，否则驱动会触发默认的SSL握手逻辑，和Cassandra的非SSL端口无法匹配，最终抛出All host(s) tried for query failed错误。

下面具体拆解几个可能的原因和验证方向：

1. 驱动的SSL默认行为和GUI客户端不同 #

DataStax的Java、Python等驱动，在默认配置下，可能会优先尝试SSL端口（通常是9142），或者如果没明确禁用SSL，就会自动启用SSL握手逻辑。而TablePlus的“Disabled”是直接连接非SSL端口（默认9042），完全不触发SSL相关流程。

举两个常用驱动的配置示例，你可以参考调整：

• Java驱动需要显式调用禁用SSL的方法：

Cluster.builder()
       .addContactPoints("172.17.0.3")
       .withPort(9042)
       .withoutSSL() // 关键：明确禁用SSL
       .build();

• Python驱动需要在配置里清空SSL选项：

from cassandra.cluster import Cluster

cluster = Cluster(
    contact_points=['172.17.0.3'],
    port=9042,
    ssl_options=None  # 显式禁用SSL配置
)

2. 端口配置不匹配 #

从你的nodetool status来看，节点地址是172.17.0.3，Cassandra默认非SSL端口是9042，SSL端口是9142。如果你在TablePlus里手动指定了9042，但DataStax驱动默认用了9142（SSL端口），那就算想禁用SSL，连接到SSL端口也会失败。务必确认驱动配置里的端口是9042。

3. 驱动版本带来的行为差异 #

不同版本的DataStax驱动对SSL默认配置的处理不同，比如部分新版本会默认启用SSL，而旧版本是默认禁用。你可以核对下自己用的驱动版本，对应官方文档确认默认行为——如果是新版本，必须显式禁用SSL才能连接非SSL端口。

快速验证步骤 #

• 先检查Cassandra的cassandra.yaml，确认native_transport_port是9042（非SSL端口），native_transport_port_ssl是9142（如果开启的话）。
• 在驱动配置里同时指定9042端口+显式禁用SSL，再尝试连接。
• 开启驱动的DEBUG日志，查看连接过程中的具体错误细节（比如握手失败、端口超时），能帮你精准定位问题。

内容的提问来源于stack exchange，提问作者Varad