在工作中、团队协作时，可能遇到的问题，如集成测试等场景。但是作为偏前端的全栈，锅从天上来，不是你想甩就能甩，尤其面对测试等比较强势的团体（bug创造者），你必须有强大的心理承受能力+冷静的分析。
我会记录一次次的经历，复盘分析和分享，以便大家以后能不背锅而爱工作(#^.^#)
一 上下文环境描述
- 部署使用docker compose
- 应用是nodejs app
- 数据库使用sqlite, prisma引擎
- 宿主机 ubuntu server，一个远程的虚拟机内
- 网络环境是内网nat
- 前端应用使用iframe集成到主应用
二 问题沟通记录
- 测试：提bug了，升级版本后看不到页面，报502，已截图
编辑
- 我：这关我啥事，我这边都没用到nginx
- 测试：是你这边的页面打不开！而且是xx提交新版本之后，之前都没问题的
- 我：那我看看
- 我：是从jenkins下载的最新archive包吗？
- 测试：是的啊！你看就是这儿
- 我：（好像没错）看看你的部署yml文件
- 测试：就改了个版本号（捣鼓了一阵）
- 我：那你把版本改回去看看
- 测试：之前是没问题的
- 我：先回退看看是不是没问题
- 测试：奇怪，也报错了（捣鼓一阵）
- 我：这是网络问题（巴拉巴拉一阵，报错有prisma push的时候，无法访问一个地址）
这时候，锅其实在我们这边了，内网docker部署，按理说，不该还需要访问外网的。但之前不知道这个，心里分析了下，应该是同步schema的时候，命令还是配置不对，但我们可不能认怂，改或者亲自研究可需要不少时间，所以：必须甩出去，然后悄悄改好！
- 我：你访问下这个网址，curl localhost:3000
- 测试：连不上 （remote reset, nodejs没跑起来，能脸上才怪）
- 我：curl一下这个报错的prisma地址
- 测试：也连不上
- 我：复制链接，在外面windows跑
- 测试：可以访问
- 我：这就是校验版本（我看页面是一个hash值，盲猜是校验hash确定版本完整性的）
- 测试：该咋办？
- 我：在里面ping一下baidu
- 测试：咦，ping不通
- 我：测试下route
- 测试：route没问题啊，是xxx.254
- 我：之前能启动？
- 测试：是的
- 我：是不是改什么网络配置了？巴拉巴拉（这时候一定要专业，脱口而出一大堆路由、防火墙、Nat的关键字）
- 测试：我没改啊
- 我：那可能是IT改了（反正不是我改的，而且网络都是IT部门控制的）
- 测试：那这就不好办了，还要测试呢
- 我：咦，你试着外面ping一下百度，拿到ip再里面ping ip
- 测试：ip可以通（一通操作）
- 我：那是dns出问题了
- 测试：哦，我确实改过一点东西，改了dnsname（说着cat了一个文件）
- 我：这里配置不对吧（虽然没见过这文件，但是个yml类似的，里面有route字段盲猜是路由配置to-via，还有个nameservices，我看就赔了一个本地的地址）
- 测试：这是配的ad域得地址
- 我：还加两行，114.114和8.8
- 测试：之前也没啊，就把这个默认路由所在ip改成了现在这个
- 我：先改了试试（我盲猜是因为以前默认路由作为dns服务时，它会把dns请求继续往上抛直到某个默认的DNS去）
- 测试：好了，可以通了（佩服）
- 我：那就好，以后改网络配置要注意啊（然后潇洒的走回去了）
三 复盘总结
- 先别接锅，没确定是我们的问题，不要假定是我们的问题（哪怕我们也有问题），不然会错过一些额外的原因，毕竟一次获得更多收获更好
- 别觉得麻烦，反正都是上班时间，就当离开休息下，毕竟指导人定位问题，比自己一直写代码会轻松一点点，尤其是写太久
- 要好好根据场景过一遍相关的知识点，哪怕不是很熟悉，关键字或者它的描述要记得
四 知识点解析
4.1 域名访问都需要DNS解析
只要是通过非ip使用http，都需要经过dns解析，Domain Name Solve，它类似于一个将域名映射到某个ip地址（http是基于ip协议的，所以发送出去之前需要知道目的地ip）
4.2 DNS解析先经过主机配置的ip映射
主机一般可以定义dns解析，例如windows的hosts文件，linux一般在/etc/hosts
4.3 DNS其次解析会经过DNS服务器
如果主机的配置没有包含目标域名，则会请求dns服务器
五 DNS服务器配置
5.1 windows
通过设置-网络和internet-连接界面配置
5.2 CentOS 配置自定义DNS服务器地址
5.2.1 编辑网络配置文件
在CentOS中，DNS服务器地址可以通过修改网络接口配置文件或全局的DNS配置文件来进行。
修改网络接口配置文件（适用于使用NetworkManager的系统）：
一般网络配置文件位于 /etc/sysconfig/network-scripts/ifcfg-<interface_name>，例如：
sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
在文件中，找到或添加如下的配置：
DNS1=8.8.8.8 DNS2=8.8.4.4
修改、增删、保存文件并退出。
5.2.2 重启网络服务
为了使更改生效，必须重启网络服务或系统。
sudo systemctl restart NetworkManager
或者，针对特定的网络接口重启服务：
sudo ifdown eth0 && sudo ifup eth0
5.2.3 验证DNS设置
可以通过以下命令验证DNS是否配置正确：
cat /etc/resolv.conf
5.3 Ubuntu 配置自定义DNS服务器地址
Ubuntu系统上，特别是使用systemd-resolved的版本，可以通过Netplan或直接配置DNS进行设置。
5.3.1 使用Netplan配置（Ubuntu 18.04及以后）
Netplan是Ubuntu的新网络管理工具，配置文件通常位于 /etc/netplan/ 目录下。例如，编辑 50-cloud-init.yaml 文件：
sudo vi /etc/netplan/xxx.yaml
在对应的网络接口下，找到 nameservers 部分，修改为你想要的DNS服务器地址：
network: version: 2 ethernets: eth0: dhcp4: yes nameservers: addresses: - 8.8.8.8 - 8.8.4.4
保存并退出后，测试Netplan配置：
sudo netplan try
如果没报错就可以应用配置：
sudo netplan apply
5.3.2 通过 systemd-resolved 配置（推荐）
对于使用 systemd-resolved 的Ubuntu版本，可以通过 systemd-resolved 进行配置：
编辑 /etc/systemd/resolved.conf 文件：
sudo nano /etc/systemd/resolved.conf
找到或取消注释 DNS= 行并添加自定义DNS服务器：
DNS=8.8.8.8 8.8.4.4
保存并退出后，重启 systemd-resolved 服务：
sudo systemctl restart systemd-resolved
5.3.3 验证DNS设置
与CentOS类似，可以通过以下命令查看配置是否生效：
cat /etc/resolv.conf
如果你使用的是 systemd-resolved，可以使用 systemd-resolve --status 查看详细信息。
六 总结
6.1 修改DNS服务器地址要小心
如果需要指向自定义的域名，若是单个地址，修改hosts文件会更快更稳。指向某个自定义dns服务器时，不要去掉了原来的dns服务器地址，而是添加地址
6.2 url不可达先分析DNS其次是路由
如果不是ip的地址，切勿忘记先检查DNS，哪怕觉得没有改什么
希望从我这次经历，前端想转后端的小伙伴等，能够学会分析和定位网络问题哈。有什么想补充的，欢迎留言
