📖 背景
新项目要开发一个后台评估模块，同事用AI跑了一版基础代码，我的任务是启动服务、调试Bug、修复问题。
项目用的是微服务架构，依赖一个配置中心来拉取数据库地址、账号密码等关键配置。启动脚本里有一个前置检查，必须能连上配置中心才能继续启动。
💥 事故现场
在我的个人电脑上，用公司的VPN连入内网，执行团队标准的启动脚本时，报了这个错：
text
BLOCK: xxx node endpoint is not reachable: http://xxx.xxx.com/get_server_nodes现象：
-
脚本连一个内网域名失败了
-
报错直接终止了脚本，服务压根没启动
-
整个启动流程还没走到应用启动那一步就停了
🔍 排障过程（按时间线）
第一步：验证网络是否真的不通
我先验证了VPN本身是否正常，用了一个内网数据库域名来做对照测试：
powershell
Test-NetConnection -ComputerName xxx.db.xxx.com -Port 5000结果：
text
ComputerName : xxx.db.xxx.com
RemoteAddress : 10.xx.xx.xxx
RemotePort : 5000
TcpTestSucceeded : True✅ 网络是通的：数据库能连上，说明VPN本身没问题。
第二步：尝试解析报错的配置中心域名
既然数据库能通，我单独测了一下配置中心这个域名：
bash
curl -v http://xxx.xxx.com/get_server_nodes结果：
text
* Could not resolve host: xxx.xxx.com
curl: (6) Could not resolve host❌ DNS解析失败：电脑根本不认识这个域名是什么IP。
第三步：确认DNS问题
用 nslookup 确认一下当前用的是哪个DNS：
bash
nslookup xxx.xxx.com返回显示DNS服务器不是公司内网的，而是我本地的公共DNS（比如路由器或运营商的）。
问题初步定位：
VPN连上了（网络通了），但DNS解析请求没有走VPN通道，还是走的本地的DNS服务器，所以解析不了内网域名。
第四步：对比公司环境 vs 在家环境
为什么同样的脚本，在公司能跑，在家跑不了？
| 环境 | 网络 | DNS服务器 | 内网域名解析 |
|---|---|---|---|
| 公司（办公室） | 公司WiFi | 公司内网DNS（自动下发） | ✅ 能解析 |
| 家（VPN） | VPN连入 | 本地DNS（路由器/运营商） | ❌ 不能解析 |
根本原因：
-
公司的VPN使用了分裂隧道模式 （Split Tunneling）：只有访问内网IP的流量走VPN，DNS解析请求还是走的本地DNS。
-
本地DNS服务器里没有注册公司的内网域名，所以解析失败。
✅ 解决方案
方案一：配置hosts文件（临时绕过DNS）
这是最快的解法。找一位在公司内网的同事，让他帮忙解析一下这个域名：
bash
ping xxx.xxx.com拿到内网IP（类似 10.xx.xx.xxx），然后配到本地的 hosts 文件中：
Windows ：C:\Windows\System32\drivers\etc\hosts
添加一行：
text
10.xx.xx.xxx xxx.xxx.com保存后重新 curl 测试：
bash
curl -v http://xxx.xxx.com/get_server_nodes这次如果返回了 502 Bad Gateway 或其他响应，说明域名解析问题已经解决。剩下的就是配置中心服务本身的问题了。
优点 ：5分钟搞定，立即见效
缺点：如果内网IP变了，需要更新hosts
方案二：配置VPN为"全隧道模式"（根治方案）
在VPN客户端中，将VPN模式从分裂隧道 切换为全隧道，让所有网络请求（包括DNS解析）都走VPN通道。
优点 ：一劳永逸，所有内网域名都能解析
缺点：VPN可能不支持此配置，或者需要管理员权限
方案三：手动修改网络DNS为内网DNS（根治方案）
将电脑的DNS服务器地址手动设置为公司的内网DNS服务器地址（需要向IT或运维获取）。
优点 ：一劳永逸
缺点：如果VPN不转发DNS流量，改了也没用，需要配合全隧道模式使用
方案四：本地配置文件，彻底绕过配置中心（终极备用方案）
如果环境问题长期解决不了，可以让应用完全不依赖配置中心，从本地的 application-local.yml 读取配置，然后用 -Dspring-boot.run.profiles=local 启动。
优点 ：完全不依赖内网环境，本地想怎么跑怎么跑
缺点：需要自己维护一套完整配置，且可能和团队配置脱节
📝 知识沉淀
核心结论
"VPN连上了" ≠ "所有网络流量都走了VPN"
特别是DNS解析请求，很可能还是走的本地网络，导致内网域名解析失败。
排查方法论
遇到类似问题时的标准排查路径：
text
1. ping 域名
├── 能通 → DNS没问题，检查端口/服务状态
└── 不通 ↓
2. ping IP
├── 能通 → DNS解析有问题
│ └── 解决方案：配hosts / 换DNS / 配置VPN
└── 不通 → VPN网络本身有问题
└── 解决方案：检查VPN连接状态、路由表关键检测命令
| 目的 | 命令 | 说明 |
|---|---|---|
| 测网络连通性 | ping 域名或IP |
最基础的连通性测试 |
| 测指定端口 | Test-NetConnection -Port 端口（Win） nc -zv 地址 端口（Mac/Linux） |
确认端口是否开放，服务是否存活 |
| 查看当前DNS | nslookup 域名 |
确认DNS解析结果和使用的DNS服务器 |
| 查看路由表 | route print（Win） netstat -rn（Mac/Linux） |
确认哪些网段走了VPN |
| 测试HTTP接口 | curl -v 地址 |
看完整请求响应，确认是DNS问题还是服务问题 |
为什么公司电脑能跑，家里不行？
| 场景 | DNS服务器 | 能否解析内网域名 |
|---|---|---|
| 公司内网 | DHCP自动下发公司DNS | ✅ 能 |
| 家用VPN（分裂隧道） | 本地DNS（运营商/路由器） | ❌ 不能 |
| 家用VPN（全隧道） | VPN下发的公司DNS | ✅ 能 |
🚀 后续进展
配置完hosts后，配置中心域名解析问题解决。继续往前走时又遇到了502 Bad Gateway（配置中心服务本身不可用），这是服务端的问题，需要联系运维或确认测试环境状态。
但这已经是另一个层面的问题了------DNS这一关，我们已经彻底闯过去了。
💡 一句话总结
排障的本质是分层------网络层通不通？DNS层能不能解析？服务层活不活？每层独立排查，就不会被卡住。