应先检查Oracle监听器是否运行、端口是否被占用及防火墙是否拦截：执行lsnrctl status确认监听状态，netstat检查1521端口LISTENING状态及绑定IP（非127.0.0.1），再验证Navicat中host填服务器真实IP、port与listener.ora一致，并确保防火墙/安全组放行该端口。
检查 Oracle 监听器是否真正运行在目标端口
navicat 连不上 oracle，报 ora-12170: tns:connect timeout occurred，第一反应不是改 navicat 设置，而是确认监听器有没有在跑、端口有没有被占、防火墙有没有拦。很多人直接跳过这步，反复重装客户端或调 tnsnames.ora，结果白忙。
- 登录 Oracle 服务器，执行
lsnrctl status—— 如果返回 “The listener is not currently running”，说明监听根本没启，lsnrctl start才是正解 - 监听默认端口是
1521，但可能被修改。看$ORACLE_HOME/network/admin/listener.ora里的PORT值，别只信文档默认值 - 用
netstat -an | grep 1521（Linux）或netstat -ano | findstr :1521（Windows）确认端口是否处于LISTENING状态，且绑定的是0.0.0.0或具体 IP，而不是127.0.0.1（后者远程连不上）
Navicat 连接配置里 host 和 port 必须与监听实际暴露一致
很多人填了正确的 SID 或 Service Name，却栽在 host 上：比如服务器真实 IP 是 192.168.5.100，但 Navicat 里写了 localhost 或 127.0.0.1 —— 这等于让 Navicat 去连自己本机的 Oracle，当然超时。
- host 字段必须填 Oracle 数据库所在机器对外可访问的 IP（非
127.0.0.1），如果走域名，确保本地能nslookup解析成功 - port 必须和
listener.ora中ADDRESS段的PORT完全一致；常见错误是监听配了1522，连接时却填1521 - Service Name 和 SID 不可混用：12c+ 推荐用
Service Name（查SELECT value FROM v$parameter WHERE name = 'service_names';），旧版本或单实例常用SID（查SELECT instance_name FROM v$instance;）
Oracle 服务器防火墙和中间网络设备会静默丢包
即使监听起来、Navicat 配对了，也可能卡在 TCP 握手阶段——防火墙或云平台安全组没放行端口，连接请求发出去就没了回音，Navicat 等满 60 秒直接报超时。
- Linux 上检查
iptables或firewalld：例如sudo firewall-cmd --list-ports看1521/tcp是否在列表里 - 云服务器（阿里云/腾讯云/AWS）务必检查安全组规则，入方向要放行对应端口，源 IP 可先设为
0.0.0.0/0测试，确认通了再收紧 - 用 Navicat 所在机器执行
telnet 192.168.5.100 1521（Windows）或nc -zv 192.168.5.100 1521（macOS/Linux）：如果连不上，说明网络层不通，不用往下调 Oracle 配置
tnsnames.ora 不影响 Navicat 直连，但影响部分高级功能
Navicat 默认走“简易连接”（即直填 host/port/service name），不读本地 tnsnames.ora。所以改了这个文件，Navicat 连接没变化是正常的，别因此怀疑配置没生效。
- 只有在 Navicat 连接类型选了 “Oracle (TNS)” 并指定
TNS Admin路径时，才会加载tnsnames.ora；绝大多数人用的是 “Oracle (Basic)” 类型 - 如果误启用了 TNS 模式又填错路径，会报
ORA-12154: TNS:could not resolve the connect identifier，和超时无关，别混淆 -
tnsnames.ora的典型错误是括号不匹配、换行符损坏、中文空格混入——这类问题只影响 TNS 解析，不影响基础 TCP 连接
真正卡住的点往往藏在监听状态、IP 绑定、防火墙三层里，而不是连接字符串格式。尤其注意监听器绑定的是 127.0.0.1 还是 0.0.0.0，这个细节多数人不会去查，但一查一个准。
