打开浏览器，代理输入一个域名，网站敲下回车。代理页面加载出来，网站你看到的代理是某个网站的内容。但你可能不知道，网站这个网站真正的代理服务器可能在美国、德国或者新加坡，网站而你访问的代理只是一个反向代理。

反向代理这个东西，网站说白了就是代理一台站在服务器前面的“中间人”。用户以为自己连的网站是目标网站，实际上连的代理是代理服务器。代理服务器替用户去跟真正的网站后端服务器要数据，再把数据原样递回来。代理整个过程用户完全无感。

我最早接触反向代理是因为一个很实际的问题。朋友做了个小工具站，服务器放在日本，国内访问速度时好时坏，丢包严重的时候页面直接打不开。后来他在香港租了一台小机器，装了Nginx，配了几行反向代理规则，把日本那台机器藏到后面。用户访问香港节点，香港节点再去日本取数据。延迟从原来的三四百毫秒降到了几十毫秒。就这么简单。

Nginx是目前用得最多的反向代理软件。配置写起来不复杂，一个server块，一个location，加上proxy_pass指向后端地址，基本就能跑起来。Apache也能做，Caddy也行，但Nginx的生态和资料量摆在那里，遇到问题搜一下大概率有人踩过同样的坑。

反向代理和正向代理的区别经常有人搞混。正向代理是替客户端出头的——你翻墙用的那种代理就是正向代理，服务器不知道你是谁，但知道你要去哪里。反向代理反过来，它替服务器挡在前面，用户不知道背后到底有几台机器、分别在哪里。一个隐藏客户端，一个隐藏服务端。方向不同，用途也完全不同。

除了加速访问，反向代理还能干不少事。比如负载均衡——后端挂三台服务器，代理层按轮询或者权重把请求分下去，某台挂了自动摘掉。比如SSL termination——证书装在代理层，后端只跑HTTP，省去每台机器都配证书的麻烦。再比如缓存静态资源，图片、CSS、JS这些不常变的东西直接由代理层返回，后端压力能降一大截。

不过反向代理也不是万能药。代理层本身会成为一个新的瓶颈点，配置不当的话可能比直连还慢。DNS解析、连接复用、缓冲区大小这些参数都需要根据实际情况调。我见过有人照抄网上的配置，proxy_buffer_size设了个默认值，结果后端返回大文件的时候频频报502。排查了半天才发现是缓冲区太小，代理层等不及后端响应就断了连接。

还有一点容易被忽略：反向代理会改变客户端的真实IP。后端服务器看到的全是代理的IP，日志里清一色的127.0.0.1或者内网地址。要做访问统计或者封禁IP的话，得在代理层加X-Forwarded-For或者X-Real-IP头，后端再从这个头里取真实IP。多一步配置的事，但不知道的人能在这上面卡很久。

现在云服务商基本都提供现成的反向代理服务，AWS的ALB、Cloudflare的CDN本质上都是反向代理的变体。用起来确实省事，点点鼠标就配好了。但理解底层原理还是有用的，至少出问题的时候你知道该从哪里下手查，而不是对着控制台干瞪眼。

自己搭一个反向代理其实花不了多少时间。一台最便宜的VPS，装个Nginx，写几行配置，十分钟搞定。搞一次就明白了。