正向代理和反向代理

正向代理站在浏览器这边，替浏览器去访问外面的网站。反向代理站在服务器这边，替后面的程序接收外面的访问。

两边都叫代理，差别在请求往哪边走，以及对方看见的是谁。

请求往哪边走

正向代理时，你的电脑先把请求交给代理，代理再去访问目标网站。目标网站看到的是代理的地址，不是你的电脑。公司网络里统一上网，或者浏览器里手动填的 HTTP 代理，就是这种。请求是从内网往外走。

反向代理时，浏览器以为自己在访问网站本身。实际上请求先到了 Nginx 或 Cloud Run 的入口，再由它转给后面的程序，把响应交回来。浏览器不用知道后面有几台机器。请求是从外网往里走。

前端也可以加上反向代理。现在的 Maki 没有用。

公司的办公电脑没有直接连接外网的权限，只能访问公司内网。公司部署一台正向代理服务器，比如 Squid 或 Clash。

程序员在电脑上配置代理：

export http_proxy=http://10.0.0.1:8080

要下载 GitHub 上的依赖包时，请求先发给 10.0.0.1。这台代理代替电脑去连接 GitHub 并下载数据。公司可以在代理上记录员工的上网日志，也可以禁止访问特定网站。

爬虫如果短时间内频繁请求同一个网站，容易被封 IP。付费的正向代理 IP 池就是用来换出口地址的。

爬虫发起请求时，把请求发给正向代理。代理随机选一个公网 IP 去抓取数据，再把结果返回给爬虫。对目标服务器来说，每次请求的 IP 都不一样。

前端项目（React 或 Vue）部署在 3000 端口，后端 API（Node.js 或 Spring Boot）跑在 8000 端口。浏览器如果从 3000 直接请求 8000，会触发跨域（CORS）报错。

部署一个反向代理（比如 Nginx），统一对外暴露 80 端口：

对浏览器来说，所有请求都在同一个域名和端口下，跨域问题就不存在了。

后端有三台一样的 Order 服务：10.0.0.2:8080、10.0.0.3:8080、10.0.0.4:8080。

客户端只请求 https://api.example.com/order。入口的反向代理收到请求后，用轮询（Round-Robin）依次打到不同机器上。某台机器宕机，反向代理把它剔除，客户端无感知。

反向代理不是只能用 Nginx。Nginx 是目前最知名、性能很高的工具之一，很多专业的网关和反向代理在特定场景下比它更合适。选哪一个，看的是流量怎么分、后面的服务怎么扩，而不是工具的名字。