反向代理的代理服务器是作用在客户端还是服务端

很多人第一次配中转站时会卡在这个问题上：Base URL 填的是中转域名，那这个「代理」到底代理了谁？如果它在客户端一侧，为什么我本机不用装任何东西；如果它在服务端一侧，那我换台电脑为什么还得改配置。这篇不绕概念，直接按请求走的路径逐段标位置，再给一套判断顺序，让你遇到「该改客户端还是该改服务端」时能自己定位。

很多人第一次配中转站时会卡在这个问题上：Base URL 填的是中转域名，那这个「代理」到底代理了谁？如果它在客户端一侧，为什么我本机不用装任何东西；如果它在服务端一侧，那我换台电脑为什么还得改配置。本文不绕概念，直接按请求走的路径逐段标位置，再给一套判断顺序，让你遇到「该改客户端还是该改服务端」时能自己定位。

结论先放这里：反向代理的代理服务器作用在服务端一侧，它站在上游模型服务前面，替上游接收来自四面八方的客户端请求。你的客户端只是把它当成一个普通 API 地址，所以本机不装任何东西也能用；换机器要改配置，改的也只是这个地址和鉴权方式，跟你本地环境没关系。

先看请求从哪到哪：一次调用经过的几段路

把一次调用拆成四段：客户端程序 → 本地到公网这段网络 → 反向代理服务器 → 上游模型服务。反向代理落在第三段，也就是紧挨上游那一侧。你的客户端出网之后，第一站敲到的就是代理服务器的域名，而不是模型服务本身。返回时路径反过来，代理再把结果交给你的客户端。

正向代理

代表客户端去访问外部资源，配置装在客户端这一侧，浏览器或系统里填代理地址就是它

反向代理

代表服务端来接收请求，入口域名指向服务端，客户端不需要知道背后有几台机器

名字里的「反」

说的是方向不是能力，谁被代理谁就是受益方，客户端侧装的是正向，服务端侧接收的是反向

理解这一点后很多现象就顺了：为什么你本机不用装任何代理软件？因为入口域名指向的就是对方服务器，你的客户端只是把它当成一个普通的 API 地址在用。代理在不在，客户端根本不感知，它只认一个能连上的地址和一个能通过的 Key。

• 客户端改的只有两处：Base URL 换成代理域名，鉴权头换成代理方发给你的 Key
• 代理那一侧负责：把请求转发给上游、带上上游凭证、按规则做限流和日志、把返回体按原格式吐回来
• 上游模型服务那一侧：只看到代理服务器的来源，看不到你的真实客户端，也看不到别的客户端
• 你的本机网络环境：除了能不能连通，几乎不参与这次调用的逻辑，所以换台电脑同一份配置照样能用

为什么它算服务端角色：三个可观察的信号

不用背定义，看三个现象就能判断它站在哪一侧。第一个是配置的可移植性：把同一份客户端配置拷到另一台机器，只要网络通就能用，说明变化的是服务端入口，不是你的本地环境。如果它在客户端侧，那你换机器、换系统、换浏览器都会牵一发动全身。

第二个信号是密钥和策略的位置。上游密钥、限流规则、路由分发、访问日志，这些全都发生在你看不见的那一侧。客户端手里只有一个统一域名和一个自己的 Key，代理拿这个 Key 认人，再拿自己的上游凭证去说话。第三个信号是自建时的落点：如果你自己搭一套转发，要处理的是域名、证书、转发规则和上游凭证，全是服务端侧的事；反过来客户端侧通常只改 Base URL 和鉴权头，工作量完全不在一个量级。

遇到配置分歧时的判断顺序

实际排障时，先别急着改配置，按下面的顺序判断改哪一层。第一步确认你动的是什么：只动 Base URL 或鉴权头，那是客户端侧；要动域名解析、证书、转发规则，那是服务端侧。这一步定错了，后面全白忙。

1. 确认改动层级只改 Base URL / 鉴权头 → 客户端侧；要碰域名解析、证书、转发规则 → 服务端侧。先在纸上写清楚你要改的是哪一类，再动手。
2. 看报错形态连不上、证书报错、域名解析失败，通常是服务端入口问题；鉴权失败、字段不认、模型名不存在，一般是配置与协议层的问题。
3. 确认是否自建自建的转发，排错按「入口可达 → 转发规则 → 上游凭证 → 返回体格式」走一遍，每步用最小请求验证一次，别跳步。
4. 补上特殊链路如果客户端被企业网络强制走正向代理，链路里会多出一跳，位置判断要跟着改，这时客户端侧确实多了一层配置。

什么情况下不适用这套顺序？当你的网络环境中存在客户端侧的正向代理，或者客户端拿到的不是普通 HTTP 接口而是被包装过的 SDK，链路里就会多出参与者。这时先厘清多出来的那一跳是谁配的、归谁管，再套上面的判断，不然容易把服务端入口问题误判成客户端配置问题。想核对不同中转入口的实际表现，可以到站内页面查当时的记录，再决定动哪一层。

判断标准就三条：改的东西属于哪一侧、报错指向哪一环、链路里有没有多出来的代理跳。三条对上了，就知道该去改客户端还是该去改服务端，剩下的只是按顺序验证。