反向代理和URL重写，代理这俩名字听起来都像在“改地址”，写技但干的代理事完全是两码事。我见过不少刚入门的写技朋友把两者混为一谈，结果排查问题的代理时候绕了老大弯路。

先说结论：反向代理不是写技URL重写技术。它俩是代理网络架构里两个不同层面的工具，碰巧都跟“请求地址”沾点边。写技

反向代理的代理核心是“转发”。你访问一个域名，写技比如`api.example.com`，代理反向代理服务器收到请求后，写技会把整个请求原封不动地丢给后端的代理某台真实服务器——可能是`192.168.1.10:8080`，也可能是写技另一台云服务器。客户端根本不知道后端在哪，代理它只跟代理打交道。这就像公司前台，访客说“找张三”，前台不会告诉访客张三坐在哪张桌子，而是自己把访客领到张三工位前。前台干的是“引路”的活，不是“改名”的活。

URL重写呢，是“改地址”本身。它发生在Web服务器或反向代理处理请求的过程中，把请求的路径从A改成B，然后再继续处理。比如你访问`/product/123`，重写规则把它变成`/index.php?id=123`，服务器内部按新地址去执行代码。用户浏览器地址栏里的URL可能没变，但服务器内部看到的已经是改写后的样子。这更像公司内部的工单系统——你把单子提交给“售后部”，系统内部自动把它转给“技术支持组”，但对外你只知道你提交了售后。

有意思的是，很多反向代理软件（比如Nginx）同时支持URL重写功能。这就容易让人产生错觉，以为反向代理就是干重写这件事的。我用Nginx举个实际例子：

location /api/ {  proxy_pass http://backend_server/; } 

这段配置是反向代理——把`/api/`下的所有请求转发到`backend_server`。而下面这段是重写：

rewrite ^/old-path(.*)$ /new-path$1 last; 

注意看，`proxy_pass`把请求整个丢出去了，而`rewrite`只是改动了请求的URI，改完以后服务器可能自己处理，也可能再走别的location块。一个是“把球传给别人”，一个是“把球改个方向继续踢”。

我见过一个真实案例：有个团队把网站所有静态资源URL都做了一层混淆加密，用反向代理解密后转发到真实存储服务器。他们一开始用URL重写来做，结果发现重写规则越写越复杂，性能也扛不住。后来改成反向代理——在代理层做解密，把解密后的原始路径转发给后端，代码干净利落。这俩技术配合起来能解决复杂问题，但各自的分工完全不同。

还有个容易混淆的点：反向代理能改变客户端看到的URL吗？能，但那是通过“代理转发”间接实现的。比如你访问`example.com`，代理把它转发到`internal-server:8080`，用户看到的还是`example.com`。这确实让URL“看起来变了”，但本质是代理隐藏了后端地址，不是重写。重写是服务器内部对URI的修改，代理是对整个请求的“换目的地”。

所以下次再有人问你，反向代理是不是URL重写，你可以直接说：不是。反向代理是“帮你把请求送到该去的地方”，URL重写是“把请求的路径改成另一个样子”。前者解决的是“谁处理请求”的问题，后者解决的是“请求长什么样”的问题。要是把这两件事混在一起想，配置出错的时候，你连该查哪段配置都不知道。