一、http反向代理到底是个啥
先说人话版本：反向代理就是站在服务器前面的一道"前台"。用户访问网站时，请求其实先打到了这台前台机器上，前台再把请求转交给后面真正干活的服务器，把结果原路返回给用户。整个过程里，用户从头到尾都以为自己连的就是网站本身，压根不知道后面还有几台机器在工作。
举个生活里的例子：你打公司总机，接线员帮你转接到具体某个部门。你只记住了总机号码，不知道分机在哪、有几个人在接电话、谁今天休假。总机就是反向代理，分机就是后端服务器。
从技术角度看，一个标准的 http 反向代理通常做这几件事：
1. 接收请求：监听 80/443 端口，接住来自浏览器的 HTTP/HTTPS 请求；
2. 转发请求：按照配置好的规则，把请求交给后端的某一台服务器（这个过程叫 upstream 转发）；
3. 回传结果：把后端返回的内容整理好，再发给用户；
4. 顺带处理杂活：加解密 HTTPS、压缩内容、记录日志、限流、缓存静态文件等。
所以它不是一个"可有可无的中间商"，而是现代网站架构里非常核心的一层。你访问的绝大多数中大型网站，第一跳几乎都是反向代理。
二、正向代理和反向代理，一字之差差在哪
很多人把这两个概念搞混，其实区分标准只有一句话：这个代理是替谁办事的。
正向代理替客户端办事。你在自己电脑上配置一个代理地址，浏览器所有请求先发给代理，代理再替你去访问目标网站。目标网站看到的是代理的 IP，看不到你的真实 IP。典型用途是隐藏来源、多地区访问测试、采集数据时分散请求来源。
反向代理替服务器办事。用户什么都不用配置，甚至不知道它存在。它站在服务端一侧，帮服务器挡住流量、分发请求、隐藏真实源站地址。典型用途是负载均衡、缓存加速、安全防护、多服务统一入口。
| 对比维度 | 正向代理 | 反向代理 |
|---|---|---|
| 服务对象 | 客户端（用户） | 服务端（网站） |
| 部署位置 | 靠近用户侧 | 靠近服务器侧 |
| 隐藏的是谁 | 隐藏客户端的真实 IP | 隐藏后端服务器的真实地址 |
| 客户端是否需要配置 | 需要，主动填写代理地址 | 不需要，用户无感知 |
| 典型使用场景 | 数据采集、多账号运营、访问测试 | 负载均衡、缓存加速、安全防护、统一入口 |
| 是否常做缓存 | 一般不缓存 | 大量缓存静态资源与页面 |
记住这个公式就够了：正向代理 = 我找人替我去访问；反向代理 = 网站找人替它接客。
三、一个请求经过反向代理的完整路径
理解了区别，再看流程就轻松多了。以你打开一个商品页为例：
第一步，浏览器把请求发到域名对应的 IP，这个 IP 其实是反向代理服务器的；
第二步，反向代理根据域名、路径、请求头等条件，判断该交给哪台后端服务器；
第三步，后端服务器处理业务逻辑、查数据库、拼页面；
第四步，结果回到反向代理，由它加上缓存头、压缩、补上安全响应头，再返回给浏览器。
这里有个细节值得注意：后端服务器看到的来访者 IP，默认是反向代理的 IP。所以配置里通常要加上转发头信息（比如 X-Forwarded-For），否则后端日志里全是同一个地址，排查问题会很痛苦。
四、反向代理常见的部署场景
反向代理之所以几乎成了标配，是因为它一个组件能顶好几个活儿。
1. 负载均衡。后端有多台服务器时，反向代理按轮询、权重、最少连接等策略把请求分下去，某台机器挂了就自动跳过，业务不中断。
2. 缓存加速与动静分离。图片、CSS、JS 这类静态资源由反向代理直接返回，不用每次都打到后端程序，回源次数少了，响应自然快了。
3. 安全防护。真实源站 IP 不对外暴露，外面只能看到反向代理的地址。配合限流、黑名单、请求体大小限制，能挡掉不少恶意扫描和异常刷量。
4. 统一入口与路径分发。微服务架构下，前台一个域名，/api 转给接口服务，/admin 转给后台服务，/static 直接读文件，用户看到的是一个网站，背后是一堆服务。
5. HTTPS 卸载。证书只在反向代理这一层装一次，后面的内网服务继续跑 HTTP，省事又省性能。
6. 灰度发布。按请求头或比例把一小部分流量导到新版本服务器上，出问题随时切回来。
五、动手：一份能跑起来的 Nginx 反向代理配置
反向代理不一定非得用 Nginx，但它确实是最常见的选择。下面这份配置把"转发 + 转发真实 IP + 静态缓存"三件事都写进去了：
server {
listen 80;
server_name api.example.com;
# 静态资源由反向代理直接返回，减少回源
location /static/ {
root /data/www;
expires 7d;
}
# 动态请求转发给后端服务器组
location / {
proxy_pass http://backend_pool;
# 把用户真实 IP 传给后端
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;
# 超时与连接复用
proxy_connect_timeout 5s;
proxy_read_timeout 30s;
proxy_http_version 1.1;
}
}
upstream backend_pool {
server 10.0.0.11:8080 weight=3;
server 10.0.0.12:8080 weight=1;
keepalive 32;
}改完记得执行 nginx -t 检查语法，再 nginx -s reload 平滑生效。上线后先看两件事：后端日志里能不能看到真实用户 IP，以及访问大文件时响应头里有没有带缓存标识。这两点对了，说明配置基本到位。
六、入站靠反向代理，出站也要有靠谱的代理 IP
反向代理管的是"别人怎么进来"，但很多业务还有一半的需求在"我们怎么出去"。比如爬虫要给每个采集任务分散出口、多账号运营要给每个账号配独立出口、接口联调要在不同网络环境下验证返回结果——这些场景里，需要的是正向代理方向的代理 IP 服务，和反向代理正好是互补的两条链路。
天启HTTP 是国内 IP 代理服务商，提供 HTTP / HTTPS / SOCKS5 协议的代理 IP，支持 API 提取与隧道转发两种取用方式，节点覆盖国内主要城市，适合数据采集、多账号管理、接口测试等出站场景。它的特点是接入简单：拿到 IP 和端口后，在程序或浏览器里填上就能用，不需要改动你现有的反向代理架构。
一个常见的组合是这样：外部用户 → 你的反向代理 → 后端业务 → 业务程序通过天启HTTP的代理 IP 去访问外部目标站点。入站有反向代理兜底，出站有代理 IP 分散，两条链路各司其职，日志和限流也都能各管各的。
需要说明的是，天启HTTP 的代理 IP 只适用于国内网络环境的访问场景，如果你的业务目标站点在境外，那它并不合适；同时它提供的是机房类代理 IP，不涉及住宅类资源，选型时请按自己的实际需求来判断。
常见问题
Q：http 反向代理和负载均衡是一回事吗？
不是。反向代理是"站在服务器前面的转发层"这个角色，负载均衡是它常干的一件事。反向代理可以只做转发不做均衡（只有一台后端），负载均衡也可以由专门的硬件或四层组件来完成。
Q：反向代理一定要用 Nginx 吗？
不一定。Nginx、Apache、Caddy、HAProxy 都能做，云厂商的负载均衡服务本质也是反向代理。选哪个主要看你团队熟悉什么、并发量多大、要不要图形化配置。
Q：用了反向代理，网站会更安全吗？
会好一些，但别指望它万能。它的价值在于隐藏源站地址、统一做限流和访问控制、集中处理 HTTPS。真正的安全还要靠后端代码、权限设计和日志监控配合。
Q：为什么加了反向代理之后，后端日志里的 IP 全一样？
因为后端看到的是反向代理的地址。解决办法是在反向代理配置里加上 X-Real-IP 和 X-Forwarded-For 请求头，并让后端程序从这两个头里读取真实用户 IP。
Q：反向代理会影响访问速度吗？
理论上多了一跳会有一点点开销，但实际大多数情况反而更快：静态资源被缓存、连接被复用、后端压力被分摊。如果明显变慢，优先检查是不是没开缓存、上游连接没复用，或者反向代理机器本身的带宽和 CPU 吃满了。
Q：反向代理能配合代理 IP 一起用吗？
可以，而且很常见。反向代理负责入站流量的接住与分发，代理 IP 负责业务程序出站访问时的出口分散，两者不冲突。使用天启HTTP的代理 IP 时，只需在业务程序或请求库中设置代理地址即可，不需要改动反向代理的配置。
Q：小网站有必要上反向代理吗？
一台服务器也值得。哪怕只为了统一做 HTTPS、加缓存头、挡掉扫描流量，反向代理这一层都很划算，后期扩容时也不用再改架构。
