虚拟机tns超时，绝大多数情况下不是Oracle数据库本身“死”了，而是从你的客户端到虚拟机数据库这条链路上的“网络握手”没走通。这个问题在本地开发环境里尤其常见，折腾半天往往发现是防火墙、IP配置或者监听器地址写错了，下面我把最常见的几个坑按可能性从高到低排一遍，你对照着排查，大概率能解决问题。
虚拟机的网络模式是第一个要查的“隐形杀手”
很多人在本地装完Oracle没动过网络配置,结果宿主机死活连不上，先看一眼虚拟机的网络模式。
虚拟机通常有三种网络模式：NAT模式、桥接模式、仅主机模式，如果你用的是NAT模式，虚拟机的IP是内网段（比如192.168.x.x），宿主机一般能通，但局域网里其他电脑想连这个数据库，基本连不通，因为NAT模式相当于虚拟机躲在宿主机后面，外面的人敲门敲不到它。
具体排查思路：
- 在虚拟机里执行
ip addr或ipconfig，确认IP地址段。 - 在宿主机上执行
ping 虚拟机IP，看通不通。 - 如果不通,先把虚拟机的网络模式改成桥接模式，让虚拟机和宿主机处在同一个局域网网段。
- 改完后重启虚拟机,再重复ping测试。
行业共识认为,约七成虚拟机TNS超时问题出在网卡模式与物理网络环境不匹配，尤其是在公司网络里，如果交换机开了端口隔离，桥接模式也可能不通，这时候就需要找网管放通权限。
防火墙把Oracle的1521端口给“闷”住了
网络能ping通,不代表端口就通，Oracle默认监听端口是1521，很多系统自带的防火墙会默认拦截外部对这个端口的访问。
分两步排查：
- 在虚拟机内检查防火墙状态，Linux下执行
systemctl status firewalld，Windows下检查“Windows Defender防火墙”是否开启了公用网络禁止入站规则。 - 在宿主机上测试端口连通性，Windows执行
telnet 虚拟机IP 1521，如果提示“无法打开连接”或直接卡住不动，基本可以断定是防火墙拦截了1521端口。
解决方案也很直接：
# Linux（CentOS/RHEL系） firewall-cmd --permanent --add-port=1521/tcp firewall-cmd --reload # 如果用的是ufw sudo ufw allow 1521/tcp
Windows虚拟机就把防火墙里“入站规则”新增一条“允许TCP 1521端口”，注意
虚拟机里如果装了多张网卡，确保监听地址绑定的是你用的那张网卡的IP，别绑定到另一个网段的虚拟网卡上去了。
监听器（listener）根本没接上你提供的地址
有时候防火墙放了,网络也通，但TNS还是超时，这时候问题往往出在 listener.ora 文件的配置上。
在虚拟机里打开 $ORACLE_HOME/network/admin/listener.ora，重点看这两行：
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 你的主机名)(PORT = 1521))
)
)
这里面的 HOST 参数非常关键，如果你填的是 localhost 或者 /etc/hosts 里映射的乱七八糟的主机名，外部客户端拿真实IP来连接，监听器可能根本不响应。
建议把 HOST 改成虚拟机的真实IP，或者填 0.0.0 表示监听所有地址，改完执行：
lsnrctl reload
然后执行 lsnrctl status，看输出里 Listening Endpoints Summary... 下面的地址，是不是包含了你期望的那个IP和1521端口。
有一个很隐蔽的坑：hosts文件里把主机名解析到了127.0.0.1，Oracle在启动监听时优先从 /etc/hosts（Windows是 C:WindowsSystem32driversetchosts）里解析主机名，如果解析到回环地址，监听器就会绑在127.0.0.1上，外面自然连不进来。
tnsnames.ora 里写的地址跟实际不匹配
客户端这边也有坑,你在宿主机上装的Oracle客户端或PL/SQL Developer，连接串写在 tnsnames.ora 里，很多人在里面写了 HOST = localhost，以为localhost就是虚拟机，这就不对了。
正确的写法是：
VM_ORCL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.100)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = orcl)
)
)
这里的 HOST 必须是虚拟机对外可达的IP地址，不是虚拟机的机器名，更不是localhost。SERVICE_NAME 要和数据库里 show parameter service_names 查出来的值一致。
排查时在宿主机上用 tnsping VM_ORCL 测试。tnsping 能通但SQL连接超时，说明tnsnames解析正常，问题出在数据库监听或权限层
。tnsping 本身就超时，问题一定在网络层、防火墙或监听器地址绑定上。
sqlnet.ora 里的超时参数把耐心耗尽了
数据库端还有个配置文件叫 sqlnet.ora，里面有连接超时控制参数，默认值可能很短，网络稍有抖动就判定超时。
重点看两个参数：
SQLNET.OUTBOUND_CONNECT_TIMEOUT：客户端发起连接后等待服务器的最大时间（秒）。SQLNET.INBOUND_CONNECT_TIMEOUT：服务器端接受连接后等待客户端完成身份验证的时间。
如果这两个值设置得特别小,网络延迟一高就超时，建议调到合理范围：
SQLNET.OUTBOUND_CONNECT_TIMEOUT = 10 SQLNET.INBOUND_CONNECT_TIMEOUT = 30
另外还有一个不太起眼但容易被忽视的：SQLNET.EXPIRE_TIME，这个参数是设置探活间隔的，如果网络链路不稳定（比如wifi连接虚拟机），建议设置这个值，让数据库定期探测客户端是否存活，避免半开连接堆积导致新连接无法建立。
改完 sqlnet.ora 不需要重启监听，但需要重连新的会话才会生效。
虚拟机资源耗尽导致监听线程来不及响应
这个场景在大数据量或并发高的环境里比较典型,虚拟机分配的内存或CPU太少，数据库进程频繁做swap，监听器线程得不到CPU调度，连接请求就会堆积。
具体表现就是：你 tnsping 通，防火墙没问题，配置也对，但SQL连接就是转半天然后超时。
查看虚拟机CPU和内存：
top free -h
如果CPU一直100%，或者内存swap占用持续增长，优先考虑给虚拟机多分配些资源，很多人的VMware虚拟机只分配了1核1G内存就硬跑Oracle，不超时才怪。
另外还有一种情况是磁盘IO瓶颈，Oracle在创建会话时需要读写一些临时文件，如果虚拟磁盘所在的物理硬盘已经是“满载”状态，也会导致连接超时，这种情况在机械硬盘上比SSD上更常见。
本地连接虚拟机 oracle 超时？按这个顺序查一遍最省时间
上面讲了五个方面,下面按照实际排查顺序做个总结，可以直接照着操作。
- 先在虚拟机里
lsnrctl status，确认监听器活着，且监听地址不是127.0.0.1。 - 在宿主机
ping 虚拟机IP，不通就改网络模式。 telnet 虚拟机IP 1521，不通就放通防火墙。- 在宿主机
tnsping 你的连接串别名，通不过就检查tnsnames.ora里的IP和端口。 - 全通了但SQL还超时,就去调
sqlnet.ora超时时间，并观察虚拟机资源占用。
ORA-12170 和 tns-12535 报错归纳
你可能会在网上看到各种报错代码,这里简单归类一下，业内专家指出，ORA-12170（TNS连接超时）和 ORA-12535（监听器无法响应）本质上都是连接握手失败，区别在于前者更偏向客户端视角的网络不可达，后者更偏向服务端资源或配置问题。
| 报错代码 | 含义 | 最可能原因 |
|---|---|---|
| ORA-12170 | 连接超时 | 防火墙/网络不通/IP地址错 |
| ORA-12535 | 操作超时 | 监听器负载高/资源耗尽 |
| ORA-12514 | 服务名找不到 | tnsnames里service_name写错 |
| ORA-12541 | 无监听器 | listener没启动/端口错 |
遇到超时别慌,按上面表格分类判断方向，别所有问题都绕着防火墙转。
总结一个最快的判断技巧
在宿主机上做个三连测,基本能定位80%以上的问题：
ping 虚拟机IP # 通不通？不通是网络层 telnet 虚拟机IP 1521 # 通不通？不通是防火墙或监听器 tnsping 你的连接串别名 # 通不通？不通是tnsnames配置
这三步走完,问题出在哪一段就非常清楚了，绝大多数虚拟机TNS超时的根因都在这三行命令的覆盖范围里，剩下的才是Oracle配置细节问题。
常见问题解答
虚拟机里Oracle能本地登录，但宿主机连接提示tns超时，是什么原因？
本地能登录只能说明数据库进程是健康的,监听器才负责接收外部连接，建议先检查监听器绑定的地址是否包含虚拟机对外IP，再看宿主机到虚拟机的1521端口是否被防火墙拦截，多数情况下是这两个原因之一。
改了虚拟机网络模式之后IP变了，原来能连的TNS现在超时了怎么办？
IP变化后,需要同步更新两处：虚拟机内 listener.ora 的HOST参数（或保持为0.0.0.0），以及宿主机 tnsnames.ora 里的HOST地址，改完执行 lsnrctl reload 让监听器重新加载配置即可。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/630385.html
