文章目录

• 先用一句话区分正向代理和反向代理
• 正向代理：代理的是客户端
• 反向代理：代理的是服务器
• 一张流量路径图看懂二者区别
• Nginx 反向代理实战
• CDN 为什么也属于反向代理体系
• X-Forwarded-For 与真实客户端 IP
• 反向代理后的 HTTPS、Host 与 WebSocket
• 常见错误与排查方法
• 什么时候应该使用正向代理或反向代理
• FAQ：常见问题

为什么很多人会把正向代理和反向代理搞混？

正向代理和反向代理都处在“客户端与目标服务之间”，所以从表面看都像一个中间转发节点。但判断它们最简单的方法，不是看用了什么软件，而是看“代理代表谁”。

正向代理代表客户端去访问外部服务；反向代理代表服务器端接收客户端请求，再把请求转发给真正提供服务的后端。也就是说，两者最核心的区别是代理对象不同。

如果把一次 Web 请求看成“浏览器 → 中间节点 → 网站”，正向代理主要帮助浏览器一侧；反向代理主要帮助网站一侧。

先用一句话区分正向代理和反向代理

正向代理（Forward Proxy）：客户端知道代理服务器的存在，并主动把请求交给代理服务器，由代理服务器访问目标站点。

反向代理（Reverse Proxy）：客户端通常只知道对外公开的域名或 IP，并不知道真正处理请求的是哪一台后端服务器。

因此，判断一个代理属于哪一种，最实用的问题是：谁配置了它、它隐藏了谁、它代表谁发起或接收请求？

正向代理：代理的是客户端

正向代理通常部署在客户端与互联网之间。浏览器、操作系统、命令行工具或企业网络明确配置代理地址，然后由代理替客户端连接目标服务器。

常见用途包括企业统一出口、访问控制、审计、缓存，以及开发测试中的代理调试。目标网站看到的网络来源通常是代理节点，而不是客户端直接连接的出口地址。

典型路径：客户端 → 正向代理 → 目标网站。

反向代理：代理的是服务器

反向代理部署在用户与后端应用之间。用户访问 example.com 时，请求首先到达 Nginx、负载均衡器、CDN 或网关，再由它们把请求转发给 WordPress、Node.js、PHP、Java 等实际应用。

典型路径：浏览器 → DNS → 反向代理 → Web/应用服务器 → 数据库或其他内部服务。

对公网用户来说，后端可以完全不可见。这样不仅便于统一处理 HTTPS、缓存和安全策略，也可以把多个后端服务隐藏在一个域名后面。

一张流量路径图看懂二者区别

正向代理：用户设备 → Forward Proxy → Internet → example.com

反向代理：用户设备 → Internet → Reverse Proxy → App Server

正向代理隐藏或统一客户端出口；反向代理隐藏、保护并组织服务器端基础设施。一个系统中甚至可以同时存在二者。

Nginx 反向代理实战

假设公网域名为 example.com，而实际应用只监听本机 127.0.0.1:3000。Nginx 可以作为公网入口，把请求转给本机应用。

server {
listen 443 ssl;
server_name example.com;

location / {
proxy_pass http://127.0.0.1:3000;
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 $scheme;
}
}

Nginx 配置里最值得关注的并不只是 proxy_pass。Host、客户端 IP、原始协议等信息也需要正确传递，否则后端可能出现域名判断错误、日志 IP 全部变成代理 IP、HTTPS 重定向循环等问题。

CDN 为什么也属于反向代理体系

当域名接入 CDN 后，用户通常先连接 CDN 边缘节点。边缘节点可以直接返回缓存，也可以向源站回源。对于用户而言，源站位置和真实 IP 往往被隐藏。

因此从请求方向和代理对象看，CDN 的核心工作方式属于反向代理体系，只是它把反向代理节点分布到了大量边缘位置，并叠加了缓存、加速、安全防护等能力。

典型路径：用户 → CDN 边缘节点 → Nginx/源站 → 应用。

X-Forwarded-For 与真实客户端 IP

反向代理最常见的运维问题之一，是后端日志里看到的全部都是代理服务器 IP。原因很简单：TCP 连接实际上是代理节点与后端建立的。

常见做法是由可信代理写入 X-Forwarded-For，并由后端或下一层代理按可信代理链规则解析。不能无条件相信来自公网客户端自行提交的 X-Forwarded-For，因为这个请求头可以被伪造。

如果前面还有 CDN 或多层代理，必须明确哪些节点属于可信代理，再恢复真实客户端地址。安全日志、限流、风控和审计都依赖这一点。

反向代理后的 HTTPS、Host 与 WebSocket

HTTPS 在反向代理架构中常见两种方式：TLS 在代理层终止，然后使用 HTTP 与内部服务通信；或者代理继续通过 HTTPS 连接后端。哪一种更合适取决于网络边界和安全要求。

Host 头用于告诉后端用户原本访问的是哪个域名。X-Forwarded-Proto 常用于告诉应用原始请求是 http 还是 https。如果这些信息丢失，WordPress 或其他应用可能生成错误 URL，甚至产生循环跳转。

WebSocket 还需要正确处理 Upgrade 和 Connection 等请求头。普通 HTTP 页面正常并不代表 WebSocket 代理一定正确。

常见错误与排查方法

错误一：出现 502 Bad Gateway。先检查后端进程是否运行、监听地址和端口是否正确，以及 Nginx 到后端是否能够建立连接。

错误二：网站无限 301/302 重定向。重点检查 HTTPS 是否在代理层终止，以及后端是否正确识别 X-Forwarded-Proto。

错误三：日志中的访问 IP 全部相同。检查真实 IP 请求头以及 Nginx/应用的可信代理设置。

错误四：静态页面正常，API 或 WebSocket 异常。分别检查 location 匹配、超时、请求体大小以及 Upgrade 相关配置。

错误五：更换 CDN 或代理后出现缓存旧页面。需要区分浏览器缓存、CDN 缓存、Nginx 缓存和应用缓存，不能只清理其中一层。

可以直接使用的排查命令

# 查看响应头
curl -I https://example.com/

# 查看完整请求与握手过程
curl -v https://example.com/

# 查看重定向链
curl -IL https://example.com/

# 绕过公共 DNS，直接测试指定源站
curl –resolve example.com:443:203.0.113.10 https://example.com/

# 在服务器本机测试后端
curl -I http://127.0.0.1:3000/

什么时候应该使用正向代理或反向代理

如果需求是让一批客户端通过统一出口访问外部网络，或者需要在客户端侧做访问控制、审计与调试，考虑正向代理。

如果需求是给网站提供统一入口、隐藏后端、做 HTTPS 终止、负载均衡、缓存、限流、WAF、CDN 回源或多服务路由，考虑反向代理。

大型系统中两者并不冲突。例如公司电脑先经过企业正向代理访问互联网，而目标网站又通过 CDN 和 Nginx 反向代理进入内部应用。

FAQ：正向代理和反向代理常见问题

Q：Nginx 只能做反向代理吗？
A：Nginx 最常见的用途之一是 HTTP 反向代理和负载均衡。具体代理能力取决于协议、模块和部署方式，不能简单把所有 Nginx 场景都概括成同一种代理。

Q：CDN 和反向代理有什么区别？
A：CDN 通常包含分布式反向代理能力，但还增加边缘缓存、调度、回源、安全等完整体系，所以 CDN 不只是“一台反向代理服务器”。

Q：反向代理会提高网站速度吗？
A：不一定。合理的连接复用、缓存、压缩、边缘节点和负载均衡可以改善体验，但配置错误也会增加延迟。代理本身不是性能提升的保证。

Q：用了反向代理就安全了吗？
A：不是。反向代理可以隐藏后端并集中部署 TLS、WAF、限流等能力，但应用漏洞、弱口令、错误权限和后端暴露等问题仍然需要单独解决。

Q：怎么确认请求经过了代理？
A：可以结合 DNS、响应头、服务器日志、curl -v、traceroute/网络抓包以及代理配置综合判断。不要只根据某一个响应头下结论。

总结

正向代理和反向代理的名称看起来相似，但理解它们并不复杂：正向代理主要代表客户端，反向代理主要代表服务器。

实际部署中，更重要的是把请求路径画清楚：用户首先连接谁、TLS 在哪里终止、谁负责缓存、真实 IP 如何传递、请求最终进入哪个应用。只要把这条链路弄清楚，很多 502、重定向循环、真实 IP 丢失和缓存异常问题都会更容易定位。

对于网站运维而言，Nginx、CDN、负载均衡器和应用服务器往往共同组成一条反向代理链。配置时应同时考虑可用性、性能、安全和可观测性，而不是只关注“能不能打开页面”。

发布建议

保留原文章标题、固定链接（URL）和原发布日期。只替换正文后更新文章；确认前台目录、代码块、移动端换行正常，再进行百度推送。