事情是这样发生的（背景）：

    我需要在弹性云的机器上部署一个 Web Page Server， 这个 Server 是基于 Webpack Dev Server 运行的，其中还要完成一个对 HTTP 请求进行代理的功能。
    需要先声明一下，我没有多少操作系统查询和配置的经验，很多问题都需要临时借助搜索引擎了解。可能于我而言更多是一个从“未知”到“可理解并解决问题的已知”的过程。

    问题的暴露（表象）：

    当我尝试将 HTTP 请求，代理转发到 intra.xxx.com （鉴于隐私保护，本文中的具体域名及 IP 将使用虚构的代替）时，Webpack Dev Server 报出异常：

    1. proxyReq error: getaddrinfo ENOTFOUND intra.xxx.com

    定位问题（找到根本原因）：

    首先我们明确 intra.xxx.com 上是有服务的，我本机（Mac OS）上是能成功访问其服务的。
    在服务没有问题的情况下，一般从客户端就是两个环节可能出问题：

    1. intra.xxx.com 域名解析到 IP；
    2. 访问 IP；

    从报错信息 “getaddrinfo ENOTFOUND” 我们可以推测很可能是域名解析出错了。但还需要验证一下：

    Note: 这种验证的作用，不仅是能够确认我们对根源问题的猜想（因为报错信息往往并不能准确传递出根源问题，只能说是一个重要的线索 clue，它的可靠性是有限的），而且可以在后续尝试解决问题时，用于验证问题是否成功地被解决了（这个行为可能是反复多次的）。

    验证方式：直接对 intra.xxx.com 进行域名解析
    经过搜索，我发现 dig 是个最常用的域名解析工具，同样通过搜索引擎的帮助在弹性云的机器（CentOS）上安装了 dig。

    Note: 当搜索某件事（比如，安装 dig）的具体实现方式时，一定要搞清楚这件事是由软件系统中哪个部分（操作系统）负责的，该部分的具体实现又跟什么有关（操作系统的类型和版本，CentOS 7），因此我们搜索 “install dig & CentOS 7” 是比较恰当的。

    通过 dig intra.xxx.com ，我们发现确实是域名解析失败了：

    $ dig intra.xxx.com

; <<>> DiG 9.10.6 <<>> intra.xxx.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35414
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;intra.xxx.com.  IN      A

;; Query time: 20 msec
;; SERVER: 192.168.5.1#53(192.168.5.1)
;; WHEN: Thu Oct 28 09:57:24 CST 2021
;; MSG SIZE  rcvd: 57

    标识 dig 结果成功与否的信息是 status。当 status 为 NXDOMAIN 时，代表解析失败了，其原因可能是没有找到相应的记录，或者记录不存在。

    其实刚开始时，我关注的信息是 ANSWER: 0，因为通过对比一些成功的解析报告，我发现它们通常有一个或多个 ANSWER。通过搜索 “dig & no answer”，我从搜索结果中找到了一些线索：

    并且根据线索，我大致明白了“至少要了解哪些 dig 规则才可能理解并解决问题”。从而找到了一个满足需要的简明规则。

    结合对 dig 基础规则的理解和前面的一些线索，我发现了一个非常有可能解决问题的新线索：

    再结合在我本机上是可以成功访问 intra.xxx.com 服务 的这一事实，我从本机上找到能够成功解析 intra.xxx.com 的 DNS 服务器 172.23.18.1。在快速验证其在弹性云的机器上有效后，将其设为了弹性云机器的默认 DNS 服务器。

    快速验证 DNS 服务器 172.23.18.1 的有效性：

    $ dig @172.23.18.1 intra.xxx.com

; <<>> DiG 9.10.6 <<>> intra.xxx.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36623
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;intra.xxx.com.  IN      A

;; ANSWER SECTION:
intra.xxx.com. 3600 IN   A       100.69.24.18

;; Query time: 5 msec
;; SERVER: 172.23.18.1#53(172.23.18.1)
;; WHEN: Thu Oct 28 17:26:23 CST 2021
;; MSG SIZE  rcvd: 73

    在还没确定解决方案的有效性之前，优先采用低成本的方式，快速验证有效性，在确认之后，再执行更为彻底全面的解决方案。因为在不能未确定有效性之前，盲目乐观的执行解决方案，往往会导致很多高成本的无功而返。（实在是浪费时间，欲速则不达。）

    问题到这里就解决了。其实真正的过程，还有很多小的挫败和相关规则发现，以及尝试不从根源解决问题而绕路的失败。但是我想本文中记录下来的部分，能够基本地阐明我在这次 Debug 过程的一些思考。也许过程是曲折，但是真理却是直接的，希望自己在解决问题时，能够沿着根源的道路上多坚持一会，也多预留一些时间用于做这样的事情。