服务器能访问外网却访问不了内网或特定服务，绝大多数情况是路由表错乱、防火墙拦截或服务监听地址不对，按“路由→防火墙→服务绑定”的顺序排查就能定位。
服务器能上外网但打不开内网，问题可能出在哪？
这个故障很常见：服务器在机房放着，外网地址能通，访问公司官网、拉取软件源都正常，可一旦要访问内网那台ERP服务器，或者连一下同网段的数据库，就卡住、超时,甚至直接被拒绝。
“外通内不通”的现象，几乎都指向同一个方向：数据包没有走对出口，能访问外网，说明默认路由是通的；内网访问不通，说明通往内网网段的路由可能缺失、冲突，或者被防火墙中途拦截，不管是北京机房的物理机、上海云主机的实例，还是本地办公室的虚拟服务器，排查逻辑完全一致，与其花几百块找外部支持，不如先用下面这套方法自己过一遍，多数情况下，故障集中在三个层面：路由表、防火墙服务、服务自身的监听地址。
服务器无法访问内网地址？按这套流程一步步排查
动手之前，先别急着敲命令，把现象描述清楚：是全部内网地址不通，还是只有特定服务不通？是完全连不上，还是通了但很慢？范围不同,排查方向差别很大。
第一步：确认IP网段和网关配置
进服务器先看网络配置，Linux执行 ip addr 和 ip route，Windows执行 ipconfig /all 和 route print，重点确认两件事：内网网卡的IP地址和访问目标是否在同一网段，以及内网网卡是否配置了正确网关。
举个例子，服务器内网IP是192.168.1.10，想访问192.168.2.20的数据库，两个网段不一样，就必须有一条去往192.168.2.0/24的路由，或者靠内网网关转发，如果内网网卡没配网关，而系统默认路由又指向外网口，数据包就会被稀里糊涂地丢到外网出口,绕一大圈肯定回不来。
第二步：检查路由表里的默认路由优先级
这是最容易踩坑的地方，装了双网卡的服务器，一张接外网、一张接内网，系统会生成多条默认路由，优先级由metric值决定，数值越小越优先，问题就出在这里：如果外网口的默认路由metric更小，所有流量都往外网口送,内网流量自然出不去。
Linux下用 ip route show 查看，找到 default via
开头的几行，核对哪条路由优先级最高，需要让内网流量走内网口时,手动加静态路由就行：
ip route add 192.168.2.0/24 via 192.168.1.1 dev eth1Windows下对应的命令是 route add 192.168.2.0 mask 255.255.255.0 192.168.1.1 -p，加 -p 参数让路由在重启后依然保持，这个操作看着简单，但确实解决了相当一部分“服务器能上外网但打不开内网”的案例。
第三步：用ping和端口测试缩小范围
路由确认没问题，再开始测连通性,在服务器上按顺序执行几个测试：
ping 内网网关：不通，问题在二层，查网线、交换机端口和VLANping 目标机器IP：通了，说明链路正常，问题在上层；不通，继续查路由或防火墙telnet 目标IP 端口或nc -vz 目标IP 端口：IP通但端口不通，基本锁定是防火墙拦截或服务没起来
做完这三步，故障范围已经缩小到网络层或传输层,接着往下走就行。
linux服务器无法访问内网其他机器，重点关注这三处
如果你的服务器是Linux发行版，排查思路可以再深入一层，行业共识认为下面三个原因出现的频率最高,依次检查基本不会漏。
路由表“抢流量”：内网数据包走了错误出口
上面提到的双网卡路由冲突，在Linux上尤其明显，特别是用NetworkManager管理的桌面版系统，或者云服务器加了额外网卡的情况，系统经常同时存在两条默认路由，查看 ip route show，如果发现多个 default via,用下面命令删掉多余那条：
ip route del default via 旧网关地址也可以用 ip route replace default via 新网关 dev 网卡名 强制指定唯一出口，注意，这个操作只对当前会话生效，如果要永久保存，得写进网卡配置文件或 /etc/rc.local。
iptables或firewalld把内网流量拦在门外
Linux防火墙默认策略如果是DROP，又没有放行内网网段，就会出现“外网能通、内网不通”的怪现象,查看当前生效规则：
iptables -L -n重点看INPUT链的默认策略和已有规则，如果默认策略是DROP,放行内网网段：
iptables -I INPUT -s 192.168.0.0/16 -j ACCEPT用firewalld的机器，执行 firewall-cmd --list-all 查看放行情况，firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.0.0/16" accept'
放行内网流量，最后记得 firewall-cmd --reload。
SELinux或AppArmor的隐形拦截
这类问题最让人头大iptables放行了，路由也对了，服务就是访问不了,很多管理员第一次遇到SELinux拦截时都在原地打转。
先执行 getenforce 看状态，如果是Enforcing，临时用 setenforce 0 切到Permissive模式测试，问题消失，说明就是SELinux策略挡了进程的网络访问，永久关闭要改 /etc/selinux/config，但不推荐直接关闭，用 ausearch -m avc -ts recent 查看具体拒绝日志，针对进程单独调整策略才是正路，Ubuntu等发行版用的是AppArmor，看了 aa-status 就能找到限制进程网络访问的配置文件。
服务器访问内网特定端口失败，先看服务绑定了哪个地址
网络通、路由对、防火墙也放行了，但内网过来说“端口连不上”，那问题多半不在网络层,而在服务本身的监听配置上。
服务只监听127.0.0.1，内网当然连不上
很多服务默认只监听回环地址，MySQL默认绑定 0.0.1，Redis早期版本默认不对外监听，Nginx某些虚机配置也只在本地监听，你以为服务已经启动了，其实它只对服务器自己开了门,内网其他机器根本拿不到钥匙。
检查命令是 ss -tlnp（Linux）或 netstat -ano（Windows），看目标端口对应的是 0.0.1 还是 0.0.0，发现是回环地址，就修改服务配置文件，把bind地址改成 0.0.0 或具体内网IP，然后重启服务，改完之后再用 ss -tlnp 确认一次，监听地址变成 0.0.0:3306 这类形式才算搞定。
系统防火墙放行了，云安全组还在拦着
云服务器上还有一种特殊情况：服务监听地址正确，iptables也放行了，但内网访问还是不通，这时把目光移到云平台的安全组规则上。安全组是独立于操作系统之外的，服务器内部设置放行没有用，安全组没放行端口,流量压根进不到系统里。
登录简米云、酷番云或华为云的VPC控制台，找到对应实例的安全组，检查目标端口是否有来自内网来源地址的放行规则，没有就加上一条，来源填内网网段或特定IP，协议和端口跟服务一致，改完一般几秒内生效,不用重启机器。
场景对照表：不同故障现象对应哪一步排查
| 现象 | 优先排查方向 | 常用命令或操作 |
|---|---|---|
| 所有内网地址都不通 | 路由表、网关配置 | ip route、route -n |
| 内网IP能ping通但端口不通 | 防火墙、服务监听、云安全组 | iptables -L、ss -tlnp |
| 只有跨网段内网访问不通 | 静态路由缺失或冲突 | ip route add |
| 重启服务器后时好时坏 | 静态路由未持久化 | 写入网卡配置文件 |
| 外网内网互相干扰 | 双网卡metric值或策略路由 | ip rule show、route change |
常见问题解答：服务器能上外网但访问不了内网的几类典型情况
服务器能上外网访问不了内网数据库，一般是什么原因？
多数情况下是数据库服务监听了 0.0.1，只有本机能连，先用 telnet 数据库IP 3306 测端口连通性，排除网络层问题后，登录数据库查授权表，确认 user 表里是否允许了内网IP来源的连接，并执行 flush privileges 让授权生效。
双网卡服务器内外网路由冲突有什么快速判断方法？
在服务器上运行 ip route show，看是否存在两条 default via 条目，其中一条还指向内网网关，再执行 ip rule show 检查是否有策略路由打乱了选路顺序，最快速的验证方法是临时把内网网卡的默认路由移除，测试内网是否能通,能通则说明问题就出在路由优先级上。
Windows服务器访问内网特定端口失败，如何判断是不是防火墙拦截？
Windows上执行 telnet 目标IP 端口，提示连接失败时，改用PowerShell命令 Test-NetConnection 目标IP -Port 端口 验证，结果里 TcpTestSucceeded 是False，说明端口不可达，依次检查Windows防火墙入站规则、目标机器服务监听状态，以及云平台安全组的入方向策略，防火墙入站规则被误改时，在“高级安全Windows防火墙”中单独放行目标端口即可。
回到最初的问题：服务器能访问外网但访问不了内网或特定服务，思路很清晰先看路由方向对不对，再看防火墙有没有拦，最后确认服务是否监听了正确地址，按这个顺序走一遍,你自己就能找到答案。