ORA-12170连接超时——防火墙和路由的层层排查应用反馈连不上数据库报 ORA-12170等了快一分钟才报出来。登录数据库服务器看实例好好的监听也活着。这类问题十有八九不在 Oracle在网络上。这篇文章给一条从客户端到数据库的完整排查链路每一步都有可执行命令。文章目录ORA-12170连接超时——防火墙和路由的层层排查一、报错现象二、排查链路五步定位第一步确认目标 IP 和端口没写错第二步ping——先看基础路由通不通第三步telnet/nc 测端口——这步最关键第四步在数据库服务器上自查第五步防火墙——最大嫌疑人三、tcp.invited_nodes——监听器自带的黑白名单四、sqlnet.expire_time——防防火墙杀空闲连接五、验证六、预防一、报错现象ORA-12170: TNS:Connect timeout occurred完整一点的上下文通常是ERROR: ORA-12170: TNS:Connect timeout occurred超时意味着什么客户端的 TCP 连接请求SYN 包发出去后在超时时间内没有收到任何回应。这是网络层不通不是 Oracle 层的问题。这里有个重要的对照关系先记下来现象含义层面ORA-12170 超时包发出去石沉大海防火墙 DROP、路由不通、IP 错网络层Oracle 没参与ORA-12541 no listener网络通但目标端口没有进程监听网络通了Oracle 层没监听ORA-12514 / 12505连上监听器了但服务名/SID 不认识Oracle 监听层ORA-01017 等登录错误连接和监听都过了登录被拒数据库认证层按这个表从上往下排永远不要在 Oracle 层瞎查网络问题。防火墙把包 DROP 掉是最常见的 12170 原因——如果防火墙用的是 REJECT 规则客户端会很快收到 refused表现是 12541 那种拒绝DROP 规则是直接扔包不回应客户端只能干等到超时所以 12170 几乎总是和 DROP 型防火墙绑在一起。二、排查链路五步定位第一步确认目标 IP 和端口没写错听起来多余但真实案例里 IP 写错段、端口写成 1522 的比比皆是。先核对 tnsnames.ora 或 JDBC 串ORCL (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.10)(PORT 1521)) (CONNECT_DATA (SERVICE_NAME orcl)) )第二步ping——先看基础路由通不通ping192.168.1.10结果解读ttl64 time0.5 ms网络层通继续第三步Request timed out不代表死路——很多生产环境禁 ICMPping 不通但 TCP 是通的。所以 ping 不通别急着下结论直接做第三步第三步telnet/nc 测端口——这步最关键# telnet 方式超时时间用 -w 控制秒telnet192.168.1.101521# 或者 nc输出更直观nc-zv-w5192.168.1.101521三种结果对应三个方向结果含义下一步Connection succeeded/Connected to ...网络和端口全通问题不在网络回头看 Oracle 层或客户端 sqlnet 配置Connection refused网络通端口没人监听查监听器lsnrctl status、监听是否绑对地址卡住直到超时包被丢弃问题在网络路径上继续第四、五步第四步在数据库服务器上自查先确认监听器真的在对外监听不是只绑了 127.0.0.1# root 或 oracle 用户ss-tlnp|grep1521正常应该看到0.0.0.0:1521或*:1521监听所有网卡。如果只有127.0.0.1:1521外部永远连不上检查 listener.ora 的 HOST 配置。再在本机自测绕开网络验证监听本身# 在数据库服务器上sqlplus system/oraclelocalhost:1521/orcl本机通、远程不通——铁定是网络路径问题。第五步防火墙——最大嫌疑人数据库服务器上的 firewalldRHEL/CentOS 7# 看已放行的端口firewall-cmd --list-ports# 放行 1521 并永久生效firewall-cmd--permanent--add-port1521/tcp firewall-cmd--reloadiptables老系统或被安全组策略接管的环境# 看规则找有没有对 1521 的 DROPiptables-LINPUT-n--line-numbers# 放行 1521插到 DROP 规则前面-I 是插入到链首iptables-IINPUT-ptcp--dport1521-jACCEPT# 持久化否则重启失效按系统选一个serviceiptables save# 或iptables-save/etc/sysconfig/iptables中间还有网络设备/云安全组云环境阿里云、腾讯云、AWS 等要查控制台的安全组规则是否放行 1521这个不在服务器上iptables 再正确也拦不住跨机房/跨网段的还要确认中间防火墙、路由策略找网络组开通放行之后回到第三步重测nc -zv通了再连数据库。三、tcp.invited_nodes——监听器自带的黑白名单网络全通、telnet 也通但只有某台应用服务器报错查一下数据库服务器上的sqlnet.ora是否配了节点检查tcp.validnode_checking yes tcp.invited_nodes (192.168.1.5, 192.168.1.6)这个配置开启后不在 invited 名单里的 IP 会被监听器直接拒绝。注意它拒绝的表现形式是被丢弃客户端同样可能表现为超时或立即断开。处理把应用服务器 IP 加进名单所有 IP 必须写全有的版本要求连监听器自己的 IP 也写上然后重载lsnrctl reload反过来这个功能也可以当安全手段用只允许应用服务器网段连库。四、sqlnet.expire_time——防防火墙杀空闲连接和 12170 相伴的另一个高频故障连接能建立但闲置一段时间后再用就断报 ORA-03113 / ORA-03135。这不是本次连不上是上一次的连接早被掐了。原因很多防火墙、NAT 设备会清理空闲 TCP 会话常见策略 30 分钟或 1 小时清理时不通知两端。连接池里睡了一小时的连接实际早就死了应用拿到就报错。解法是在数据库端sqlnet.ora配置保活探测sqlnet.expire_time 10含义服务端每 10 分钟给空闲连接发一个极小的探测包。包一流动防火墙就不会把它当死连接清理连接真断了服务端也能立刻感知并释放资源。改完同样lsnrctl reload或等新连接生效。应用侧也可以在 JDBC 串里配 keepalivejdbc:oracle:thin://192.168.1.10:1521/orcl?oracle.net.keepalivetrue五、验证逐层回验缺一不可# 1. 网络层nc-zv-w5192.168.1.101521# 2. Oracle 监听层sqlplus system/oracle192.168.1.10:1521/orclSQL 进去后看一眼会话注册成功SELECTsid,machine,programFROMv$sessionWHEREmachineLIKE%应用服务器主机名%;能查到来自应用服务器的会话记录链路彻底打通。六、预防上线前做三件套检查ping、nc -zv、sqlplus 直连结果归档到交付文档出问题先复测对比防火墙开通工单里写明端口、协议TCP、双向云安全组同理别漏了出方向sqlnet.expire_time写进数据库装机基线尤其有防火墙/NAT 的链路应用连接池配连接有效性检测如取连接前validation query或 keepalive配合服务端探测双保险跨网段访问数据库的变更提前拉网络组一起评审——12170 的锅最后多半在网络组那侧✅ 亮点用一张四类报错分层表先定责任边界网络层/监听层/认证层再给五步排查链路每步命令可直接复制执行补充 tcp.invited_nodes 与 expire_time 两个易漏项。扩展方向VIP/SCAN 场景下的多路径排查、GoldenGate 等长连接组件的防火墙保活。 
长河君 · 2026/10/14 12:14:41 · 阅读 1.2k 17-ORA-12170连接超时防火墙与路由排查
ORA-12170连接超时——防火墙和路由的层层排查应用反馈连不上数据库报 ORA-12170等了快一分钟才报出来。登录数据库服务器看实例好好的监听也活着。这类问题十有八九不在 Oracle在网络上。这篇文章给一条从客户端到数据库的完整排查链路每一步都有可执行命令。文章目录ORA-12170连接超时——防火墙和路由的层层排查一、报错现象二、排查链路五步定位第一步确认目标 IP 和端口没写错第二步ping——先看基础路由通不通第三步telnet/nc 测端口——这步最关键第四步在数据库服务器上自查第五步防火墙——最大嫌疑人三、tcp.invited_nodes——监听器自带的黑白名单四、sqlnet.expire_time——防防火墙杀空闲连接五、验证六、预防一、报错现象ORA-12170: TNS:Connect timeout occurred完整一点的上下文通常是ERROR: ORA-12170: TNS:Connect timeout occurred超时意味着什么客户端的 TCP 连接请求SYN 包发出去后在超时时间内没有收到任何回应。这是网络层不通不是 Oracle 层的问题。这里有个重要的对照关系先记下来现象含义层面ORA-12170 超时包发出去石沉大海防火墙 DROP、路由不通、IP 错网络层Oracle 没参与ORA-12541 no listener网络通但目标端口没有进程监听网络通了Oracle 层没监听ORA-12514 / 12505连上监听器了但服务名/SID 不认识Oracle 监听层ORA-01017 等登录错误连接和监听都过了登录被拒数据库认证层按这个表从上往下排永远不要在 Oracle 层瞎查网络问题。防火墙把包 DROP 掉是最常见的 12170 原因——如果防火墙用的是 REJECT 规则客户端会很快收到 refused表现是 12541 那种拒绝DROP 规则是直接扔包不回应客户端只能干等到超时所以 12170 几乎总是和 DROP 型防火墙绑在一起。二、排查链路五步定位第一步确认目标 IP 和端口没写错听起来多余但真实案例里 IP 写错段、端口写成 1522 的比比皆是。先核对 tnsnames.ora 或 JDBC 串ORCL (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.10)(PORT 1521)) (CONNECT_DATA (SERVICE_NAME orcl)) )第二步ping——先看基础路由通不通ping192.168.1.10结果解读ttl64 time0.5 ms网络层通继续第三步Request timed out不代表死路——很多生产环境禁 ICMPping 不通但 TCP 是通的。所以 ping 不通别急着下结论直接做第三步第三步telnet/nc 测端口——这步最关键# telnet 方式超时时间用 -w 控制秒telnet192.168.1.101521# 或者 nc输出更直观nc-zv-w5192.168.1.101521三种结果对应三个方向结果含义下一步Connection succeeded/Connected to ...网络和端口全通问题不在网络回头看 Oracle 层或客户端 sqlnet 配置Connection refused网络通端口没人监听查监听器lsnrctl status、监听是否绑对地址卡住直到超时包被丢弃问题在网络路径上继续第四、五步第四步在数据库服务器上自查先确认监听器真的在对外监听不是只绑了 127.0.0.1# root 或 oracle 用户ss-tlnp|grep1521正常应该看到0.0.0.0:1521或*:1521监听所有网卡。如果只有127.0.0.1:1521外部永远连不上检查 listener.ora 的 HOST 配置。再在本机自测绕开网络验证监听本身# 在数据库服务器上sqlplus system/oraclelocalhost:1521/orcl本机通、远程不通——铁定是网络路径问题。第五步防火墙——最大嫌疑人数据库服务器上的 firewalldRHEL/CentOS 7# 看已放行的端口firewall-cmd --list-ports# 放行 1521 并永久生效firewall-cmd--permanent--add-port1521/tcp firewall-cmd--reloadiptables老系统或被安全组策略接管的环境# 看规则找有没有对 1521 的 DROPiptables-LINPUT-n--line-numbers# 放行 1521插到 DROP 规则前面-I 是插入到链首iptables-IINPUT-ptcp--dport1521-jACCEPT# 持久化否则重启失效按系统选一个serviceiptables save# 或iptables-save/etc/sysconfig/iptables中间还有网络设备/云安全组云环境阿里云、腾讯云、AWS 等要查控制台的安全组规则是否放行 1521这个不在服务器上iptables 再正确也拦不住跨机房/跨网段的还要确认中间防火墙、路由策略找网络组开通放行之后回到第三步重测nc -zv通了再连数据库。三、tcp.invited_nodes——监听器自带的黑白名单网络全通、telnet 也通但只有某台应用服务器报错查一下数据库服务器上的sqlnet.ora是否配了节点检查tcp.validnode_checking yes tcp.invited_nodes (192.168.1.5, 192.168.1.6)这个配置开启后不在 invited 名单里的 IP 会被监听器直接拒绝。注意它拒绝的表现形式是被丢弃客户端同样可能表现为超时或立即断开。处理把应用服务器 IP 加进名单所有 IP 必须写全有的版本要求连监听器自己的 IP 也写上然后重载lsnrctl reload反过来这个功能也可以当安全手段用只允许应用服务器网段连库。四、sqlnet.expire_time——防防火墙杀空闲连接和 12170 相伴的另一个高频故障连接能建立但闲置一段时间后再用就断报 ORA-03113 / ORA-03135。这不是本次连不上是上一次的连接早被掐了。原因很多防火墙、NAT 设备会清理空闲 TCP 会话常见策略 30 分钟或 1 小时清理时不通知两端。连接池里睡了一小时的连接实际早就死了应用拿到就报错。解法是在数据库端sqlnet.ora配置保活探测sqlnet.expire_time 10含义服务端每 10 分钟给空闲连接发一个极小的探测包。包一流动防火墙就不会把它当死连接清理连接真断了服务端也能立刻感知并释放资源。改完同样lsnrctl reload或等新连接生效。应用侧也可以在 JDBC 串里配 keepalivejdbc:oracle:thin://192.168.1.10:1521/orcl?oracle.net.keepalivetrue五、验证逐层回验缺一不可# 1. 网络层nc-zv-w5192.168.1.101521# 2. Oracle 监听层sqlplus system/oracle192.168.1.10:1521/orclSQL 进去后看一眼会话注册成功SELECTsid,machine,programFROMv$sessionWHEREmachineLIKE%应用服务器主机名%;能查到来自应用服务器的会话记录链路彻底打通。六、预防上线前做三件套检查ping、nc -zv、sqlplus 直连结果归档到交付文档出问题先复测对比防火墙开通工单里写明端口、协议TCP、双向云安全组同理别漏了出方向sqlnet.expire_time写进数据库装机基线尤其有防火墙/NAT 的链路应用连接池配连接有效性检测如取连接前validation query或 keepalive配合服务端探测双保险跨网段访问数据库的变更提前拉网络组一起评审——12170 的锅最后多半在网络组那侧✅ 亮点用一张四类报错分层表先定责任边界网络层/监听层/认证层再给五步排查链路每步命令可直接复制执行补充 tcp.invited_nodes 与 expire_time 两个易漏项。扩展方向VIP/SCAN 场景下的多路径排查、GoldenGate 等长连接组件的防火墙保活。