将 HTTP 发布与应用程序执行和持久数据分离。反向代理可以组织路由和限制，但源站访问、应用程序授权、上游容量和恢复各自需要自己的控制措施。
一个 Web 请求跨越多个职责
Web 服务器接收 HTTP 请求并可提供静态文件。应用程序进程执行项目的动态行为，例如检查账户或查询数据库。反向代理代表该进程接收请求并将其转发到上游。一个程序可以承担多个角色，但分离职责可以使配置和恢复更易于推理。
追踪一个请求从主机名解析到响应的过程。记录 TLS 在哪里结束、哪个进程选择路由以及哪个组件可以读取应用程序数据。对管理请求也做同样的追踪。这项练习通常会暴露为测试而创建且意外保持可达的监听器或主机名。图表应描述已部署的路径，而不是您希望构建的架构。
使用边缘来组织 HTTP 行为
NGINX 记录了提供静态内容和将请求转发到上游两种功能。其工作进程架构和 HTTP 模块提供了配置机制，但具体配置仍然决定行为。有意识地定义主机名、上游和文件系统根目录。限制可提供的文件，使配置、凭据和仓库元数据永远不会因为恰好位于应用程序附近而变得可下载。
根据应用程序为请求正文、超时和连接设置适当的限制。将缓存视为数据决策：与用户或权限绑定的内容不能未经审查就安全地继承共享缓存规则。一起测试身份验证和缓存行为。保持可复现的配置，并在重新加载服务之前验证更改，同时保留返回上一个可用版本的已知路径。
| 层 | 有用的职责 | 启动前检查 |
|---|---|---|
| 公共 Web 边缘 | TLS、主机名路由和 HTTP 限制 | 证书、根目录和预期主机名 |
| 应用程序进程 | 业务逻辑和授权 | 身份验证、输入检查和依赖故障 |
| 内部数据服务 | 持久应用程序状态 | 受限访问和经过测试的恢复 |
| 上游提供商网络 | 合同约定的网络服务 | 保护范围和升级路径 |
反向代理不会消除源站的暴露
如果源站仍然可公开访问，客户端可能绕过预期的代理路由直接访问它。当部署需要该边界时，通过网络设计和应用程序配置限制源站访问。在一台机器上，后端通常可以监听回环地址或本地套接字。跨机器时，使用明确受限的路由并对上游连接采取适当的保护。
转发标头也需要信任规则。仅从受信任的中间方接受有关原始客户端的信息，并防止任意调用方提供应用程序视为权威的值。决定访问日志和错误报告中显示的内容。代理可以改变每一层可用的信息；它不会消除账户标识符，也不会使应用程序对其自身操作者匿名。
在应用程序内部应用访问决策
NIST 的零信任架构侧重于对资源的访问决策，而不是仅基于网络位置的隐式信任。具体应用这一原则：对调用方进行身份验证，授权所请求的操作，并仅授予服务账户所需的范围。来自内部子网的请求不应自动成为管理员请求。
在可行的情况下分离公共功能和管理功能。当用户访问记录时重新检查权限，而不是仅依赖初始登录。保持代理、应用程序和数据库的凭据各不相同。分阶段引入可测试的更改，从狭窄的敏感路径开始。将部署称为零信任，不如证明禁止的操作确实在负责该操作的组件处被拒绝。
在多个层面规划拒绝服务防护
饱和的网络链路和昂贵的应用程序请求会在不同位置失败。Web 边缘的速率限制可能有助于约束请求模式，而应用程序限制可以限制搜索、上传或导出等工作。NGINX 的请求限制模块提供了一种机制；键和阈值必须适合真实用户，并经过测试以避免拒绝合法流量。
OWASP 的拒绝服务指南还涉及应用程序行为中的资源耗尽问题。为昂贵的工作设置时间和大小限制，使用有界队列并监控故障信号。本地控制无法在已经饱和的上游链路中创造容量。确认所选方案中包含的具体网络保护，并准备升级路径。切勿假设目录中的第 3–4 层保护也证明了对每个 HTTP 工作负载的保护。
将恢复作为发布的一部分
使用预期主机名从外部客户端检查站点。验证 HTTPS、重定向、静态资源、登录和具有代表性的应用程序事务。确认管理监听器和私有文件仍然不可访问。模拟上游停止，并检查边缘是否返回受控故障，而不是暴露内部细节或无限制地等待。
对于 Canvas，请阅读托管账户中可用的控制措施。对于 VPS，将 Web 边缘和应用程序作为您自己的运营计划的一部分进行维护。大网络端口是容量规格，并不能证明应用程序能够维持该吞吐量。将监控、恢复和提供商联系方式保留在运行手册中。只有在验证了实际请求路径和可行的恢复路径后才发布。
您的实用清单。
- 追踪一个公共请求和一个管理请求。
- 定义提供的根目录和上游监听器。
- 仅信任来自已批准中间方的转发标头。
- 测试授权和缓存边界。
- 为网络和应用程序故障准备限制和升级措施。
重要细节。
Web 服务器也可以充当反向代理吗？+
可以。NGINX 是一个有记录的示例。其角色取决于配置，应用程序仍然需要自己的授权和维护。
反向代理会自动隐藏源站吗？+
不会。除非路由、防火墙和监听器设置强制执行预期边界，否则源站可能仍然可达。
请求限制能阻止所有 DDoS 攻击吗？+
不能。它针对选定的 HTTP 请求模式。网络饱和和其他资源故障需要适当的上游和应用程序控制。
前往来源。
这些参考资料支持本指南中的技术概念。在更改生产系统之前，请遵循当前文档。
- NGINX：初学者指南 nginx.org
- NGINX：HTTP 请求限制 nginx.org
- NIST SP 800-207：零信任架构 nvlpubs.nist.gov
- OWASP：拒绝服务防护 cheatsheetseries.owasp.org
由 SwissOctet 提供编辑指导。示例仅作说明。服务规格、可用选项和合同条件必须单独核实。