亚马逊云美国账号 AWS亚马逊云负载均衡监听

你有没有试过——

在AWS控制台吭哧吭哧配好一个Application Load Balancer（ALB），绑了两台EC2，监听器设成HTTP:80，转发到目标组，点保存，满心欢喜打开浏览器输入域名……
结果页面显示：503 Service Unavailable。

你刷新三次，查安全组两次，重启实例一次，最后瘫在椅子上盯着CloudWatch指标发呆：我到底漏了哪根线？

别急，不是你手残，是“监听器”这个中文翻译太有迷惑性了。

它根本不是在那儿安静地‘听’流量——它是在门口扛着喇叭喊话、验身份证、查通行证、撕票、指路，一气呵成，全程不带喘气。

一、先破个幻觉：监听器 ≠ 网络监听

很多人第一次接触ALB，看到“Listener”，下意识联想到Linux的netstat -tuln或者Wireshark抓包——以为它像服务器一样，被动等着连接进来。

错！大错特错！

AWS的监听器，本质是一个主动策略引擎。它不等连接，它一上线就亮红灯、挂横幅、摆桌子、拿喇叭：“本LB只接受80端口的HTTP请求，且必须带Host头为app.example.com，否则一律请回！”

它不处理数据包，不解析TCP流，不碰应用层内容——但它会读取请求的元信息：协议、端口、Host、路径、查询参数、甚至自定义Header。然后根据你写的规则，当场拍板：放行？改头换面？重定向？还是直接甩给404？

二、监听器三件套：端口+协议+默认动作

创建监听器时，AWS只要求填三项：端口、协议、默认操作。

• 端口：比如80（HTTP）、443（HTTPS）、8080（自定义）——注意：不是EC2的端口，是LB对外暴露的入口。
• 协议：HTTP/HTTPS/TCP/TLS/UDP（ALB支持前两种；NLB全支持）。选HTTPS？恭喜，你自动获得SSL卸载能力——证书由ACM托管，后端EC2完全不用管HTTPS。
• 默认动作：这是最常被忽略的“保底开关”。比如你写了5条条件路由规则，但所有规则都不匹配？那就走这儿！常见选项：
  → 转发到某目标组
  → 返回固定响应（比如HTTP 200 OK + “Hello LB”）
  → 重定向（如HTTP→HTTPS）

记住：没有默认动作，监听器连启动都报错。

三、规则链：不是“if-else”，是“流水线+短路”

监听器真正酷的地方，在于它的规则系统——不是简单的if-else判断，而是一条有序、可中断、支持AND/OR组合的规则流水线。

举个真实场景：

1. 用户访问 https://api.example.com/v2/users
2. ALB收到请求，先看监听器：443端口HTTPS → 匹配成功，进入规则链
3. 规则1：Path is /v2/users* → ✅ 匹配 → 转发到tg-api-prod
4. 规则2：Host is admin.example.com AND Path starts-with /dashboard → ❌ 不匹配，跳过
5. 规则3：Query String contains version=beta → ❌ 不匹配，跳过
6. 亚马逊云美国账号 ……直到最后一条规则，或走到默认动作

关键细节：

• 规则按顺序执行，匹配即终止（短路），后面规则不看了；
• 单条规则可含多个条件，且默认是AND逻辑（全满足才触发）；
• 不支持OR，但可以用多条规则模拟（比如“路径是/a OR /b”，就写两条规则）；
• 条件类型丰富：Host header、Path pattern、HTTP method、Query string、Header值、Source IP CIDR……甚至支持正则（ALB v2.0+）。

四、目标组：监听器的“亲儿子”，不是“远房表弟”

很多人以为目标组（Target Group）是独立资源，监听器只是“引用”它。错！

监听器和目标组是强耦合关系。当你在规则里写“转发到tg-web”，这个tg-web必须：① 存在；② 健康检查通过；③ 注册了至少一个健康实例（或IP）；④ 健康检查路径返回2xx/3xx。

常见翻车现场：

• EC2安全组没放开健康检查端口：ALB默认用HTTP:80做健康检查，但你的EC2安全组只放了8080？→ 目标组状态变unhealthy → 流量进不来，但监听器日志里啥错误都没有，纯静音死亡。
• 健康检查路径返回500：比如/health接口依赖数据库，DB挂了→ ALB认为实例宕机→ 自动摘除→ 你还在查Nginx日志找404……
• 目标组协议不匹配：监听器用HTTPS，目标组却设成HTTP？ALB会尝试HTTPS直连后端——但你后端压根没开443！

救急命令（CLI速查）：

# 查目标组健康状态
aws elbv2 describe-target-health --target-group-arn "arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/tg-web/abcdef1234567890"

# 查监听器规则
aws elbv2 describe-rules --listener-arn "arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/my-alb/..."

五、HTTPS监听器：证书在哪？私钥去哪了？

配HTTPS监听器时，AWS会让你选ACM证书。这时候有人慌了：“我的私钥呢？我要部署到LB上吗？”

不用。一点不用。

ACM证书是AWS全托管的——私钥永远锁在AWS KMS保险柜里，你连看都看不到。ALB和ACM之间走内部加密通道，证书自动轮换、自动续期（只要域名验证通过）。你唯一要做的，就是确保ACM里证书状态是Issued，且域名匹配（example.com不能用来配www.example.com，除非SAN里包含）。

顺手送你一句咒语（避免重定向死循环）：

“如果监听器同时开了HTTP:80和HTTPS:443，请务必在HTTP监听器的默认动作里设置重定向到HTTPS，而不是转发到目标组——否则用户打http://会进后端，后端再301跳转，绕一圈又回ALB，可能触发循环。”

六、最后送你三条保命口诀

1. 查问题，先看目标组健康状态，再看监听器规则匹配日志（启用访问日志！）——90%的‘没流量’问题，根源在tg-unhealthy，不在监听器本身。
2. 规则越少越好，路径优先用前缀匹配（/api/*），少用正则——正则写错一个字符，整条规则失效，还不报错。
3. 亚马逊云美国账号 不要在一个监听器里堆15条规则。该拆就拆：HTTP:80干重定向，HTTPS:443干路由，清爽不打架。

所以，下次再看到控制台里的“Listeners”标签页，请把它想象成一个穿着马甲、戴着耳麦、手里攥着流程图、站在LB大门外的资深客服经理。

他不背锅，不甩锅，不装死——但他要求你把每张入场券（规则）写清楚、贴牢固、排好队。

你给他清晰的指令，他就还你丝滑的流量。

否则？抱歉，503不是他的错，是你没把《员工守则》（也就是那几条规则）交到位。

——毕竟，云上的世界，从来不信眼泪，只认配置。