流量全路径：公网 → ALB → 私网 EC2，以及 EC2 出网

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

你要理解的是：请求走过哪些资源、每一处检查什么、响应如何回来。 VPC 是网络边界，不是请求经过的一台设备；路由表是转发规则，SG/NACL 是不同位置的控制规则，不能全部当作串联服务器。

最关键的区别：EC2 回复 ALB 转来的请求，响应经 ALB 返回客户端；EC2 主动调用公网接口，才使用 NAT 出网。 两者不是同一条连接。

1. 本文的固定场景#

资源	配置
VPC（Virtual Private Cloud，虚拟私有云）	10.64.0.0/18
公网子网 A / B	10.64.9.0/24、10.64.25.0/24；默认路由到 IGW
私网应用子网 A / B	10.64.0.0/21、10.64.16.0/21；分别默认路由到同 AZ NAT
ALB（Application Load Balancer，应用负载均衡器）	internet-facing；部署在两个公网子网；HTTPS 443 listener
EC2（Elastic Compute Cloud，云服务器）	私网地址，无公网 IP；应用监听 8080；target group 使用 HTTP 8080
NAT Gateway（网络地址转换网关）	本例用 zonal public 模式，每个 AZ 一个，位于公网子网

IGW = Internet Gateway，互联网网关；AZ = Availability Zone，可用区；SG = Security Group，安全组；NACL = Network Access Control List，网络访问控制列表。生产可改用 HTTPS 后端，端口与健康检查规则需同步调整。

2. 公网请求进入：实际上是两段连接#

下面是逻辑转发路径与检查位置，不是 AWS 内部实现的逐包执行顺序；基础场景无自定义网关路由、检查防火墙或路由覆盖。

客户端先通过 DNS 解析业务域名到 ALB

连接一：客户端 → ALB
Internet 客户端:临时端口
  → IGW（已附加到 VPC；ALB 公网子网具备互联网路由）
  → ALB 公网子网 NACL：入站 TCP 443
  → ALB 的 SG：入站 TCP 443
  → ALB：TLS 握手、可选 WAF/身份验证、listener 与规则匹配

连接二：ALB → EC2
ALB 节点私网 IP:另一个临时端口
  → ALB 的 SG：出站到应用 SG 的 TCP 8080
  → ALB 子网路由表：目标匹配 VPC local 路由
  → ALB 子网 NACL：出站 TCP 8080
  → EC2 私网子网 NACL：入站 TCP 8080
  → EC2 网卡的 SG：允许 ALB SG 到 TCP 8080
  → 操作系统防火墙 / 监听地址 / 应用鉴权
  → 订单服务

DNS（Domain Name System，域名系统）解析发生在连接前，不是业务流量必经的中转节点。TLS（Transport Layer Security，传输层安全）在本例的 ALB 终止；WAF（Web Application Firewall，Web 应用防火墙）只有实际关联后才会检查请求。

ALB 是代理，会另外建立或复用到目标的连接。EC2 网络层看到的是 ALB 节点私网 IP，原客户端 IP 通常通过 X-Forwarded-For 请求头传递；应用只应信任受控代理传来的地址信息，不能把任意请求头当可信身份。私网目标无需公网 IP，也无需 NAT 才能被 ALB 访问。ALB 安全组规则

3. 返回客户端：不经过 NAT#

EC2:8080
  → EC2 SG：已跟踪连接的响应允许
  → EC2 子网 local 路由 + NACL 出站：ALB 临时端口
  → ALB 子网 NACL 入站：ALB 临时端口
  → ALB SG：已跟踪连接的响应允许
  → ALB 收到后端响应
  → ALB SG：客户端连接的响应允许
  → 公网子网互联网路由 + NACL 出站：客户端临时端口
  → IGW → 客户端

EC2 子网即使有 0.0.0.0/0 → NAT，去 ALB 私网地址仍命中更具体的 10.64.0.0/18 → local。路由看目标地址，不看“这次业务最初是不是来自互联网”。

4. EC2 主动访问公网：另一条连接#

例如订单服务调用支付商 HTTPS API（应用程序接口）：

EC2 私网 IP:临时端口
  → EC2 SG 出站：允许支付商 TCP 443
  → 私网子网路由表：0.0.0.0/0 → 同 AZ 的 NAT
  → 私网子网 NACL 出站：支付商 TCP 443
  → NAT 所在公网子网 NACL 入站：TCP 443
  → NAT Gateway：转换源地址/端口
  → NAT 公网子网路由表：0.0.0.0/0 → IGW
  → 公网子网 NACL 出站：支付商 TCP 443
  → IGW：映射为 NAT 的 EIP（Elastic IP，弹性公网地址）
  → 支付商防火墙 / IP 白名单 / TLS / API 鉴权

回包依次经过 IGW、NAT 子网入站 NACL、NAT 反向转换、NAT 子网出站 NACL、应用子网入站 NACL，再由 EC2 SG 的连接状态放行。NAT 没有可绑定的 SG，也不会继承 ALB 的 SG；即使两者位于同一个公网子网，资源权限仍独立。支付商看到的是 NAT 出口 EIP，不是 ALB IP。

如果应用访问 VPC Endpoint 或 Peering 对端，应按更具体路由走相应私网路径，不会一律经过 NAT。Regional NAT 不放在公网子网，不能套用本节承载子网路径，见网关与路由。

5. 最容易漏掉的规则：NACL 回包#

SG 有状态，已跟踪连接的响应自动允许；NACL 无状态，每次跨子网边界都要匹配相应方向的规则。NACL 按规则号从小到大匹配，首条匹配生效；可以显式 deny。SG 只有 allow，多个 SG 的允许规则合并，不能靠额外绑定一个“更严格 SG”抵消已有放行。连接跟踪、NACL 规则

下表全部指 TCP 目标端口，仅展示本例必需业务流量，不是可以直接替换生产 NACL 的完整清单。ALB 跨 AZ 转发/健康检查要包含所有启用 AZ 的 ALB 子网。

NACL 位置	入站允许	出站允许
ALB 公网子网	客户端 → 443；应用子网 → 1024–65535	应用子网 → 8080；客户端 → 1024–65535
EC2 私网子网	ALB 子网 → 8080；支付商地址 → 客户端临时端口	ALB 子网 → 1024–65535；支付商地址 → 443
NAT 公网子网	应用子网 → 443；支付商地址 → 1024–65535	支付商地址 → 443；应用子网 → 客户端临时端口

若 NAT 与 ALB 共用子网/NACL，需要合并两类必要规则。临时端口由发起端选择；ALB/NAT 通常按 1024–65535 放行所需回包，EC2 端按操作系统范围核对。来源/目的 CIDR 必须与真实流量匹配；NACL 不能引用 SG，也不能用域名动态跟踪支付商 IP。ALB 健康检查与 NACL 排障

健康检查也是 ALB 主动到目标的新请求：独立核对协议、端口、路径和成功状态码。若健康检查端口不是 8080，需增加对应 SG/NACL 规则。不要假设“所有目标 unhealthy”一定阻止业务转发；ALB 存在全部目标不健康时的 fail-open 行为，应使用告警与发布门禁。

6. 哪些位置会拦住请求#

位置	常见问题	证据入口
DNS	记录指错 ALB、域名解析失败	客户端解析结果、Route 53 配置
IGW / 路由表	未 attach、子网关联错误、blackhole、回程缺失	实际 association 与 routes；检查 VPC Block Public Access 是否启用
NACL / SG	NACL 先命中 deny、漏临时端口；SG 来源或端口不符	规则、VPC Flow Logs（流日志）、Reachability Analyzer（可达性分析）
ALB TLS / listener	证书域名、协议、listener 端口、Host/Path 规则错误	TLS 握手、listener rules、ALB 日志
WAF / ALB 身份验证	Web ACL 拦截、身份提供方或回调异常	WAF 日志、认证日志；HTTP 403 不一定来自 SG
Target group / 健康检查	未注册目标、端口/路径错误、应用超时	Target health 的 reason、ALB 与目标指标
EC2 系统 / 应用	只监听 127.0.0.1、系统防火墙、鉴权或依赖故障	`ss`、应用日志、依赖请求日志
NAT / 公网服务	NAT 状态、端口耗尽、出口白名单、对方限流	NAT 指标、对方记录的源 IP、HTTP 响应

网络层丢包通常表现为超时，应用可返回 401/403/500。ALB 的 502/503/504 也有多种原因，不能只凭状态码断定某张 SG 拦截。流日志 ACCEPT 仅证明该记录对应流量被网络规则允许，不证明 HTTP 成功；Reachability Analyzer 分析配置，不发实际业务请求。

7. 分步验收：把两种请求分开测#

前置：已部署的预生产 ALB/EC2，批准的测试域名、target group、应用健康路径；使用现有受控运维通道进入 EC2，不为排障临时开放公网 SSH。下列请求应选择无副作用端点。

# 1. 在客户端测公网入口；替换为实际业务域名。
export APP_HOST='REPLACE_APP_HOST'
curl --connect-timeout 5 --max-time 15 -v "https://${APP_HOST}/health"
# 2. 使用目标账号/区域的只读身份核对目标健康。
export AWS_REGION='REPLACE_REGION'
export TARGET_GROUP_ARN='REPLACE_TARGET_GROUP_ARN'
aws sts get-caller-identity
aws elbv2 describe-target-health --target-group-arn "$TARGET_GROUP_ARN"
# 3. 在目标 Linux EC2 上检查监听及进程本身。
ss -lnt
curl --connect-timeout 5 --max-time 10 http://127.0.0.1:8080/health
# 4. 仍在该 EC2 上，独立测试公网出口。
export PARTNER_HOST='REPLACE_APPROVED_PARTNER_HOST'
curl --connect-timeout 5 --max-time 15 "https://${PARTNER_HOST}/health"

验收时把同一测试时段的 ALB 日志、应用日志、流日志与支付商出口 IP 记录关联起来；使用合成请求，避免 curl -v 输出生产令牌。第 3 步成功只说明进程能响应本机请求，不能证明监听地址、SG 或 ALB 健康检查正确。

在隔离演练环境可分别移除“ALB → 目标端口”允许规则、阻断一个 NACL 回包端口、移除应用 NAT 默认路由，每次只改一项并保存原配置、立即恢复。预期前两项影响入口链路；第三项只影响主动公网调用，纯本地健康接口仍可经 ALB 响应。若健康接口本身依赖公网，则它也可能失败。SG 改动后用新连接测试，已跟踪连接可能继续存活；共享生产 NACL 不用于这种破坏演练。

把上述链路部署为真实环境，见三层子网实战。

流量路径与拦截点