导读 你给一个 Web 应用配好了域名，在终端里查一下，也能返回 IP 地址。 可浏览器还是一直转圈，最后超时。 这时最容易做的事，是回到 Route 53 反复修改记录，或者把安全组越放越宽。先停一下。DNS 查到了地址，后面的连接还没验收。 我一般会先把访问过程画成两条线。线画对了，再去看控制台，才知道每一次检查在回答什么问题。 01 · AWS 学习笔记一条线问地址，一条线真正访问
假设我们要访问 app.example.com。域名用 Route 53 解析，入口是一个面向互联网的 Application Load Balancer，也就是 ALB。应用跑在同一 VPC 的私有 EC2 上。
为了看清主线，这里只讨论 IPv4、公网 ALB、私有 EC2 这一种部署，不再叠加 CDN 或多区域切换。
上面一条是 DNS 解析。浏览器借助 DNS 解析器查询域名，拿到访问入口的地址；有可用缓存时，也可能直接使用缓存答案。
下面一条是 实际连接。浏览器拿到地址以后，才去连接 ALB。ALB 接收请求，再根据监听器规则，把请求转给目标组里的后端应用。
Route 53 的 Alias 记录可以把域名指向 ALB，但它不会替你接收、转发这次网页请求。
关键结论 查到 IP，只能说明这次 DNS 查询拿到了答案。 答案是否指向预期入口、客户端能否连上入口、入口能否找到后端，都还要继续验证。
不要把架构图画成“浏览器 → Route 53 → ALB → EC2”的一条 HTTP 流量线。这会让你误以为，后面的请求也由 Route 53 一路送过去。
02 · AWS 学习笔记公网 ALB 接得到，私有 EC2 不必暴露公网
我们让浏览器用 HTTPS 访问 443 端口，ALB 再用 HTTP 访问应用的 8080 端口。
这里有两条独立连接：浏览器到 ALB，以及 ALB 到 EC2。 两段的端口、加密方式和允许来源，都可以不同。
从公网访问 ALB，要检查它是不是 internet-facing 类型，以及 ALB 所在公有子网的路由表是否有通向 Internet Gateway 的默认路由。再看 ALB 的安全组、443 监听器和域名对应的证书。
到了后半段，ALB 访问同一 VPC 内 EC2 的私有地址。在本例的默认路由下，子网之间通过 local route 通信。
所以，EC2 可以放在私有子网，也不需要为了接收 ALB 请求而分配公网 IP。这一段也不用绕到 NAT Gateway。
NAT Gateway 解决的是私有资源主动访问外部等场景，不要因为看到“私有子网”，就把它塞进每一条访问链路里。
03 · AWS 学习笔记两侧安全组，检查的端口不一样
沿用刚才的例子，浏览器访问 443，应用监听 8080。
ALB 的安全组要允许预期客户端访问 443；它向后端发起连接时，出站规则也要允许应用端口和实际使用的健康检查端口。
EC2 的安全组则要允许 ALB 访问 8080。常见做法是把 ALB 的安全组作为入站规则来源，把应用入口收在负载均衡器后面。
如果 EC2 只放行了 443，而应用实际监听 8080，前面的域名、证书、负载均衡器都配对了，应用仍然接不到请求。
还有一种情况更容易漏：应用进程启动了，但只监听 127.0.0.1。你在实例里访问正常，ALB 从实例外访问却失败。看到“进程在运行”，还得继续确认它监听在哪个地址、哪个端口。
如果子网使用了自定义网络 ACL，也要检查相应端口和返回流量。路由表回答“往哪里走”，访问规则回答“能不能通过”，这两个问题要分别验证。
04 · AWS 学习笔记网站打不开，我会按这个顺序缩小范围
先确认 DNS 答案。 这次查询用的是哪个解析器？记录是否指向预期的 ALB？如果刚改过记录，要考虑缓存；不要一看到返回了 IP，就把整个网络打勾。
再看公网入口。 访问是连接超时，还是出现证书错误？两者指向的检查重点不同。超时先看公网可达性、路由和访问规则；证书错误要看域名与证书是否匹配。别把所有现象都归成“DNS 有问题”。
接着确认 ALB 把请求交给了谁。 监听器规则匹配的是哪个目标组？目标有没有正确注册？目标端口是不是应用实际监听的端口？
最后核对健康检查与应用响应。 比如健康检查配置为 /health，但应用只提供 /，或者返回码与检查条件不一致，就可能被标为不健康。要结合失败原因和应用日志，别只盯着红色状态继续改 DNS。
这里再补一个容易被省略的边界：ALB 有所有目标都不健康时的 fail-open 行为。因此，不能把“不健康”简单理解成“绝对不会收到请求”，更不能把“偶尔还能访问”当作配置已经正确的证据。
上面是一个便于缩小范围的检查顺序。实际排障时，明确的错误码或日志可以让你直接进入某一段，不需要每次从头机械点一遍。
评论