网络环境验证：IP配置、DNS解析、防火墙规则、端口连通性
网络环境验证，说白了就是确认你的服务器或容器在网络层面“活”了。我见过太多部署失败案例，最后查来查去，就是网络不通。今天咱们就把这四块硬骨头啃下来。
我会按照实际操作顺序来讲：先看IP配置，再看DNS解析，然后检查防火墙规则，最后确认端口连通性。这个顺序也是我团队一直用的排查路线。
IP配置验证：你配的地址真的生效了吗？
拿到一台新服务器，第一步不是跑业务。我的习惯是先看网卡状态和IP地址。
最简单的命令：
ip addr show
# 或者老系统用
ifconfig -a你注意看输出。重点检查三点：
- 网卡状态：是不是 UP。如果是 DOWN，那后面都不用看了。
- IP地址：是不是你期望的网段。我曾遇到一次，配了192.168.1.100，结果隔壁人写了一行错误配置，把地址抢了。
- 子网掩码和网关：我见过有人把/24写成/16，结果跨网段访问全不通。
确认网关：
ip route show
# 输出示例
# default via 192.168.1.1 dev eth0这里有个小坑——默认网关只能有一条。如果出现多条，系统会随机选一条。嗯，我早期在一个双网卡服务器上就吃过这个亏。
ping -c 4 网关IP 快速验证三层连通性。注意，ping通不代表一切正常，但ping不通一定有问题。
DNS解析：域名转IP这步别卡住
很多时候你的IP是通的，但服务就是连不上。为什么？因为你用了域名，但解析失败了。
我个人习惯先看 /etc/resolv.conf：
cat /etc/resolv.conf
# 期望看到类似
# nameserver 8.8.8.8
# nameserver 114.114.114.114然后做实际域名解析测试：
nslookup your-service.example.com
# 或者
dig your-service.example.com +short我曾经遇到一个情况——域名解析正确，但容器里不行。后来发现是容器内的 resolv.conf 被宿主机的配置覆盖了。你想想看，这个问题排查起来是不是很隐蔽？
还有个常见坑：DNS缓存。如果你改了DNS服务器，但系统还沿用老的解析结果，那就要清缓存：
# systemd-resolved
systemd-resolve --flush-caches
# 或者重启网络服务
systemctl restart networking| 工具 | 适用场景 | 常用参数 |
|---|---|---|
| nslookup | 快速查域名解析 | nslookup xxx.com 8.8.8.8 |
| dig | 详细调试，看全流程 | dig @114.114.114.114 xxx.com |
| host | 轻量级查询 | host xxx.com 223.5.5.5 |
防火墙规则：你以为关了就真关了吗？
网络通了，域名解析也对了，但服务就是访问不到。这时候八成是防火墙在作妖。
先看看当前防火墙状态：
# iptables 系
iptables -L -n -v
# firewalld 系
firewall-cmd --list-all
# ufw 系（Ubuntu）
ufw status verbose记住，防火墙规则是按顺序匹配的。我遇到过这样的情况：明明放行了80端口，但请求还是被拒。后来查了半天，发现前面有一条REJECT ALL规则把流量先拦截了。规则顺序很重要！
临时放行端口的方法：
# iptables 放行 8080
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
# firewalld 放行
firewall-cmd --add-port=8080/tcp --permanent
firewall-cmd --reload如果你想完全关闭防火墙做测试（仅限于测试环境）：
# systemd
systemctl stop firewalld
systemctl disable firewalld
# 或者直接清空 iptables
iptables -F实战经验：生产环境千万不要随便清空iptables。我有一次手残，在线上执行了iptables -F，SSH连接瞬间断了。那感觉……你懂的。
端口连通性：最后1%的验证
IP、DNS、防火墙都对了，最后一步——验证端口到底通不通。
最经典的命令：
telnet 192.168.1.100 8080
# 如果能连上，会显示连接成功
# 如果没反应或者显示连接失败，就是端口不通但现代系统很多默认没装telnet。我的建议是用 nc（netcat）：
# 扫描端口是否开放
nc -zv 192.168.1.100 8080
# -z 表示只扫描，不发送数据
# -v 表示输出详细信息或者用 curl 测试HTTP端口：
curl -v http://192.168.1.100:8080/health
# -v 会显示完整的握手过程为什么这些工具都能用？因为他们本质上都是建立TCP三次握手。成功建立连接，就说明网络是通的。
我曾经排查过一个奇怪的问题：A服务器telnet B服务器的3306端口通了，但是应用就是连不上数据库。后来发现——MySQL配置了只允许特定来源IP连接。telnet只管TCP握手，不管应用层认证。所以端口通不等于服务可用，这点你要记住。
- ping 网关：确认本机网络是活的
- ping 对端IP：确认三层可达
- nslookup 域名：确认DNS解析正确
- telnet IP 端口：确认应用端口开放
- curl 接口：确认服务真的在响应
嗯，到这里网络环境验证的四个核心点就讲完了。记住一个原则：分层验证，从下往上。IP层通了再看传输层，传输层通了再看应用层。跳步验证往往会让你在错误的地方花大量时间。我个人用这个路线，排查网络问题从来没超过20分钟。