DMZ层Nginx TLS 终止与安全接入配置实战20250829

【技术实战记录】DMZ 层 Nginx TLS 终止与安全接入配置实战

一、背景与目标

在 企业级系统集成场景 中，常常需要对接多家外部合作方接口。为了满足 公网访问、安全合规、统一域名规范 的需求，我在 DMZ 层的 Nginx 上增加了一个 HTTPS 接口，对外提供 /api/... 的安全访问能力。

目标

• 公网统一入口 - 合作方统一通过 gateway.example.com:6666 接入
• TLS 终止与安全控制 - 在 DMZ 层完成 HTTPS 解密、限流与安全策略
• 最小暴露面 - 只放行必要路径，其余全部拒绝
• 可观测性 - 通过健康检查与日志监控，确保系统稳定

金句小结：清晰目标是架构成功的基石，分层防护是安全的底线。

二、架构设计

整体架构流程

安全层级对比

金句小结：稳健架构如同多重关卡，层层把守，步步为营。

三、关键配置要点

1. TLS 终止

• 证书部署在 DMZ 层 Nginx；
• 仅支持 TLSv1.2/1.3；
• 禁用低版本和弱加密套件。

2. 安全控制

• 源 IP 限流（30r/s，burst 60）；
• 禁用 gzip，防止报文被改写；
• 请求方法白名单（POST/GET）；
• 非白名单路径 → 一律 404。

3. 路径转发

location ^~ /api/partner/agent/ {
    limit_req zone=req_limit_api burst=60 nodelay;
    proxy_pass http://inner_gateway;
}

location ^~ /api/partner/mis/ {
    limit_req zone=req_limit_api burst=60 nodelay;
    proxy_pass http://inner_gateway;
}

4. 健康检查

location = /healthz {
    access_log off;
    return 200 "OK";
}

配置要点总览

金句小结：配置是手段，安全是底线，两者兼顾才有稳定的系统。

四、实战中的挑战

1. 502 错误排查

• 起初在测试中遇到 502 Bad Gateway；
• 通过日志排查发现是 客户端端口配置错误（应连测试端口，却误连公网端口）；
• 再加上客户端自动重试 → 导致连续 502；
• 修正端口后请求恢复正常。

2. 路径前缀确认

需要确认内层 Nginx 是否匹配 /api/... 前缀。

验证方式：

curl http://127.0.0.1:8888/api/partner/agent/...

确认路径命中情况，避免误转发。

金句小结：问题排查就像福尔摩斯办案，细节是破案的关键，日志是最好的证据。

3. TLS 验证

curl -vk https://gateway.example.com:6666/healthz

返回：

HTTP/1.1 200 OK
...
OK

并确认 TLSv1.3 握手成功、证书链完整。

五、验证成功

健康检查 ✅

curl -vk https://gateway.example.com:6666/healthz
# 返回 200 OK

业务接口测试 ✅

请求报文 → 成功加密 → Nginx 透传 → 解密 → 响应返回正确数据，校验通过。

最终确认：整条链路 公网 → DMZ Nginx → 内层 Nginx → 后端服务 完整打通。

金句小结：好的架构不仅要跑得通，还要跑得稳、跑得安全。

六、风险控制措施

安全防护矩阵

风险控制对比

核心控制点

1. 最小暴露面 - 仅开放 /api/partner/...，其他路径全部 404
2. 限流保护 - 源 IP 限制请求速率，防止恶意刷接口
3. 加密传输 - 公网采用 TLSv1.2+，报文二次加密
4. 日志与可观测性 - 记录 $request_time/$upstream_response_time，便于性能分析
5. 兜底机制 - 健康检查 /healthz + 非业务流量直接拒绝

金句小结：风险控制不是一道墙，而是一张网——多层防护、步步为营。

七、经验总结

• ✅ 测试环境先跑通：通过 curl 和脚本多次验证健康检查与接口请求；
• ✅ 日志是最佳排查工具：502 的真正原因是端口错误 + 客户端重试；
• ✅ DMZ 层的价值：TLS 终止与安全策略前置在 DMZ，既保障安全，又简化内层业务；
• ✅ 知识沉淀：这次实战让我对 Nginx DMZ 架构、安全控制、TLS 终止 有了更深理解。

总结

好的架构不仅要 能跑通，更要 跑得稳、跑得安全。
希望这份记录对有类似需求的同学有所帮助，也作为我个人知识库的一部分，持续成长、持续分享。

附录：关键 Nginx 配置完整示例

# ===================== http{} 顶层配置 =====================
# 源IP限流配置：粗粒度入口保护
limit_req_zone $binary_remote_addr zone=req_limit_api:10m rate=30r/s;

# 上游：回到本机 8888（内层 Nginx 再分发到 71/72）
upstream mis_local_8888 {
    server 127.0.0.1:8888 max_fails=3 fail_timeout=30s;
    keepalive 64;
}

# 更可观测的日志格式（可选）
log_format full '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '$request_time/$upstream_response_time '
                '"$http_referer" "$http_user_agent" '
                'req_len=$request_length';

# 限流命中时返回码（推荐）
limit_req_status 429;

# ============================= server{} =============================
server {
    listen       6666 ssl;
    server_name  gateway.example.com;

    # 生产证书（确保证书链为 fullchain）
    ssl_certificate      /home/nginxuser/nginx/certs/example_com_20_nginx.crt;
    ssl_certificate_key  /home/nginxuser/nginx/certs/example_com_20.key;

    ssl_session_timeout  1d;
    ssl_session_cache    shared:SSL:30m;
    ssl_session_tickets  off;
    ssl_protocols        TLSv1.2 TLSv1.3;
    ssl_ciphers          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers on;

    # 密文传输显式禁压缩，避免任何内容改写
    gzip off;

    access_log  /home/nginxuser/nginx/logs/user_https_6666.access.log  full;
    error_log   /home/nginxuser/nginx/logs/user_https_6666.error.log   warn;

    server_tokens off;
    underscores_in_headers on;  # 若厂商偶尔使用带下划线的自定义头，兜底允许

    # 代理头部配置：透传客户端真实 IP
    proxy_http_version 1.1;
    proxy_set_header Host               $host;
    proxy_set_header X-Real-IP          $remote_addr;
    proxy_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto  https;
    proxy_set_header X-Forwarded-Host   $host;
    proxy_set_header X-Forwarded-Port   $server_port;
    proxy_set_header Connection         "";

    # 超时配置
    proxy_connect_timeout 10s;
    proxy_send_timeout    300s;
    proxy_read_timeout    300s;

    # 响应缓冲配置
    proxy_buffering       off;

    # 请求体大小限制
    client_max_body_size     5m;
    client_body_buffer_size  64k;
    proxy_request_buffering  on;   # 先收完请求再转发

    # ===== 业务路径配置 =====
    location ^~ /api/partner/agent/ {
        if ($request_method !~ ^(GET|POST)$) { return 405; }
        limit_req zone=req_limit_api burst=60 nodelay;
        proxy_pass http://mis_local_8888;
    }

    location ^~ /api/partner/mis/ {
        if ($request_method !~ ^(GET|POST)$) { return 405; }
        limit_req zone=req_limit_api burst=60 nodelay;
        proxy_pass http://mis_local_8888;
    }

    # 健康检查
    location = /healthz {
        access_log off;
        return 200 "OK";
    }

    # 默认拒绝：实现最小暴露面
    location / {
        return 404 "Resource Not Found";
    }
}

配置说明

1. limit_req_zone - 为源 IP 设置速率限制，每秒最多允许 30 次请求，burst=60 允许突发请求，nodelay 设置为突发请求不排队
2. upstream - 配置内层 Nginx 的回源，指向 8888 端口的后端服务
3. ssl_certificate - 配置 TLS 证书，确保公网 HTTPS 访问的安全性
4. 路径控制 - 只允许 /api/partner/agent/ 和 /api/partner/mis/ 路径的请求，通过 proxy_pass 转发至后端服务，其他路径一律返回 404
5. 健康检查 - /healthz 接口用于监控服务状态，返回 200 OK 以确认服务正常
6. 日志配置 - 记录访问日志及错误日志，以便后续审计和问题追踪