ORA-12170 表示客户端未连上监听器，属TCP层网络中断，需直接排查监听状态、TNS配置、路由及防火墙；tnsping成功不代表监听器加载服务名，须用lsnrctl status确认端点和SERVICE_NAME；注意tnsnames.ora隐藏空格、双网卡路由冲突、SELinux/firewalld拦截及Broker依赖的监听连通性。
ORA-12170 表示客户端根本没连上监听器，不是密码错、不是服务名错，是网络链路在 TCP 层就断了。直接查监听器状态、TNS 配置、路由和防火墙，别绕弯子。
tnsping 通但 sqlplus 报 ORA-12170？先看监听器是否真在监听
tnsping 只测监听器端口是否响应 SYN 包，不验证监听器是否真正加载了服务名。很多情况下 tnsping 成功，但 lsnrctl status 显示 STATUS = UNKNOWN 或压根没列出你的 SERVICE_NAME。
- 用 oracle 用户执行
lsnrctl status，确认输出里有Listening Endpoints Summary...且包含你连接的端口（如(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=*)(PORT=1521)))） - 检查
$ORACLE_HOME/network/log/listener.log最新几行，搜TNS-12535（超时拒绝）、TNS-12560（协议适配器错误），这类错误说明监听器启动失败或绑定端口被占 - RAC 环境下，每个节点都要单独执行
lsnrctl status，不能只查一个实例
tnsnames.ora 配置里藏着三个致命空格
看似正确的 TNS 条目，常因不可见字符失效。尤其注意 HASH 后、HOST 值前后、SERVICE_NAME 值末尾的空格 —— 它会让 Oracle 解析失败，报 ORA-12170 而非 ORA-12154。
- 直接从数据库服务器上拷贝
$ORACLE_HOME/network/admin/tnsnames.ora到客户端，比手动编辑安全得多 - 用
cat -A tnsnames.ora查看隐藏字符：^I是 tab，$是行尾，多出的空格会显示为普通空格 - 确保
CONNECT_DATA块里SERVICE_NAME的值，和备库实际的DB_UNIQUE_NAME完全一致（区分大小写），不是INSTANCE_NAME也不是SERVICE_NAME（主库的）
双网卡场景下路由表冲突是隐形杀手
笔记本同时连 Wi-Fi（外网）和网线（内网），系统默认把所有流量走 Wi-Fi 网关，导致连内网数据库时数据包发错方向，表现为稳定 ORA-12170。
- Windows 下运行
route print，Linux/macOS 下运行ip route show，看目标数据库 IP 所在子网是否匹配内网网卡路由 - 若内网段（如
172.10.101.0/24）没有明确路由条目，手动加：Windows 用route add 172.10.101.0 mask 255.255.255.0 172.10.101.1（网关地址）；Linux 用ip route add 172.10.101.0/24 via 172.10.101.1 dev eth0 - 临时验证可禁用 Wi-Fi，只留有线连接，如果此时能连上，就是路由问题
防火墙和 SELinux 往往静默拦截
Linux 上 iptables 或 firewalld 默认放行本地回环，但可能拦住外部连接；SELinux 更隐蔽，setenforce 0 临时关闭后能连上，基本就是它。
- 服务端执行
systemctl status firewalld或iptables -L -n | grep 1521，确认 1521 端口已放行 - 客户端也需检查本地防火墙（Windows Defender 防火墙、macOS 防火墙设置）
- 服务端执行
getenforce，返回Enforcing时，临时执行setenforce 0测试；若恢复连接，需永久允许 Oracle 端口：semanage port -a -t oracle_port_t -p tcp 1521
ORA-12170 特别容易误判 —— 它不是 Broker 自己连不上，而是 Broker 进程（dmon）尝试通过 TNS 连接配置里的所有数据库时，其中任意一个库的监听器不通，整个 Broker 就卡住不动，日志里只记一句“connect timeout”，不会告诉你具体是哪个库拖了后腿。查 $ORACLE_HOME/rdbms/log/drc<db_unique_name>.trc</db_unique_name> 才能看到真实失败点。 
