在工作中、团队协作时，可能遇到的问题，如集成测试等场景。但是作为偏前端的全栈，锅从天上来，不是你想甩就能甩，尤其面对测试等比较强势的团体（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去）
• 测试：好了，可以通了（佩服）
• 我：那就好，以后改网络配置要注意啊（然后潇洒的走回去了）

三 复盘总结

1.  先别接锅，没确定是我们的问题，不要假定是我们的问题（哪怕我们也有问题），不然会错过一些额外的原因，毕竟一次获得更多收获更好
2. 别觉得麻烦，反正都是上班时间，就当离开休息下，毕竟指导人定位问题，比自己一直写代码会轻松一点点，尤其是写太久
3. 要好好根据场景过一遍相关的知识点，哪怕不是很熟悉，关键字或者它的描述要记得

四 知识点解析

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: 2ethernets:eth0:dhcp4: yesnameservers: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，哪怕觉得没有改什么

希望从我这次经历，前端想转后端的小伙伴等，能够学会分析和定位网络问题哈。有什么想补充的，欢迎留言