很多人问「哪个更安全」，其实这个问题问错了方向：正向代理和反向代理不是两个可以平替的选项，它们暴露的对象、信任的方向完全不同。你在给自己电脑挂代理、给团队搭出口、还是给后端服务套一层入口，选错方向的后果也不一样。这篇不讲原理教科书，只讲每种结构下风险落在谁身上、上线前该核对哪几项，以及什么情况下这套判断不成立。
这个问题被问得很多，但大多数时候方向就偏了。正向代理和反向代理不是两个能平替的选项，它们把信任放在不同的地方，把风险也放在不同的人身上。你要先弄清楚自己到底想藏什么、想让谁看不见，选型才有意义。
打个比方：正向代理像你请了一个跑腿的去办事，办事的人知道你要办什么；反向代理像公司前台，外面只知道有前台，不知道里面有几个部门、坐在哪。跑腿的靠不靠谱和前台严不严格，根本是两码事。这篇只讲一件事：什么情况下哪种结构更安全，以及上线前该核哪几项。
先分清「谁在防谁」，安全差异才成立
正向代理是客户端主动把流量交给第三方，本质是你把自己的出口暴露给了中间人。请求内容、目标地址、身份凭据都可能从它手里过。它适合「我不想让目标站点知道我是谁」，但绝不适合「我不想让中间人知道我在干什么」——这两个需求经常被混在一起，结果用错了工具。
反向代理反过来，是服务端自己架在门口，客户端根本不知道后面有几台机器。它的风险在于配置错误：内部结构、真实 IP、管理接口一旦被外面摸到，就等于前门锁了后窗还开着。它适合「我要挡住外面、藏住里面」，跟隐藏用户身份一点关系都没有。
- 正向代理
- 你主动把流量交给第三方，风险在于你的出口被它看见
- 反向代理
- 服务端自己架在门口的入口层，风险在于配置不当导致内部暴露
- 判断方向
- 你要藏的是自己还是自己的服务？藏自己用正向，藏服务用反向
不适用的情况也要说清楚：如果两端都不完全可信，既不信中间人也不信对端，光换代理类型解决不了问题，得靠端到端加密或者干脆自建出口。这不是选型能兜住的。
两类代理各自的风险清单，按这个顺序核
| 检查维度 | 正向代理看什么 | 反向代理看什么 |
|---|---|---|
| 流量可见性 | 代理方是否记录明文请求、是否复用会话 | 是否正确覆写转发头、是否泄露内部主机名 |
| 身份与出口 | 退出节点是否共享、别人行为会不会算到你头上 | 回源地址能否被伪造请求绕过 |
| 入口暴露面 | 代理自身的管理接口是否对外开放 | 默认管理页与调试端口有没有关 |
| 日志留存 | 日志里能出现什么、留多久 | 日志里能出现什么、留多久 |
| 传输保护 | 是否支持加密隧道，凭据是否裸传 | 对外证书与内部回源加密是否到位 |
- 第一层：确认流量经过几层，每层能看到什么
- 第二层：确认哪些凭据会经过中间环节，能不能改成一次性
- 第三层：确认日志里会留什么，敏感字段有没有被过滤
- 第四层：最后才去调配置参数，跳步去改通常改的是不痛的那一层
- 排查顺序反过来做，容易在无关项上耗掉大半时间
共性风险是日志留存，两边都会留下访问记录，具体保留策略和处理方式站内 /log-redaction-retention 讲得比这篇细，这里不重复。你要记住的是：日志没清干净的代理层，等于给风险留了一个副本。
按场景套：哪些用法本来就该这么搭
个人开发机连外部接口、临时换出口地区，正向代理更自然。但前提是你要把「代理方能读到什么」当成既定事实，敏感凭据别裸着过，能换一次性令牌的就换。这不是能不能用的问题，是用了之后你有没有按这个前提行事。
对外提供接口或网页服务、要挡扫描和压流量，反向代理更自然。重点在入口收敛和头部治理，跟隐藏用户身份无关。这类场景最容易被忽略的是回源配置：如果回源地址可以被伪造请求绕过，前面挡得再严也没用。
- 小团队共用出口怎么判断多人共用一条出口，本质是正向代理的团队版。风险从「一个人被看见」变成「所有人互相被看见」，此时内部隔离比对外隐藏更重要，先看出口日志谁能读。
- 合规边界怎么判断如果要求明确禁止第三方中转，或数据不许出某个边界，任何代理结构都不算解。这种情况得走站内 /safety 里的合规自查思路，别在代理选型上绕。
- 切换前怎么验证先用一条不影响业务的链路试跑，确认依赖真实来源 IP 的风控、限流、审计没有异常，再决定要不要切主链路。
上线前四问，答不上来就先别切
这四问不是走流程，是筛选器。任何一问答不上来，说明你对这条链路还没摸清楚，这时候切代理不是优化而是赌博。先把答案写下来，再决定动哪一层。
- 第一问：这条链路上一共有几个能读到完整请求的环节？数不清就别上
- 第二问：出事时我能拿出哪一侧的日志？只有一侧有日志，责任就永远说不清
- 第三问：切换后原本依赖真实来源 IP 的风控、限流、审计会不会失效？这是最常见的翻车点
- 第四问：回滚要多久？代理层改动最容易「看起来正常但少了一层校验」，留好回滚路径再动
如果你手上已经有一批候选的中转或代理服务，别只看它宣传得多稳。到 /sites 按当时的检测结果核对每家的可信度，再到 /price-watch 看它们的价格变化轨迹——价格突然大幅下调的，往往对应着出口质量或节点策略的调整。具体数字以页面当时显示为准。
反向代理这边，配置侧最容易出问题的是转发头和默认页面。上线前自己从公网扫一遍，看能不能摸到管理入口、内部主机名或版本信息。能摸到，就说明这一层还没配好，别急着往前推。
最后说清楚这套判断什么时候不成立：当你既不控制客户端也不控制服务端，只是夹在中间，那么换哪种结构都不解决信任问题；当你对合规边界有硬性要求时，代理选型根本不是首要问题。这两种情况下，先把边界理清楚，再回头看代理。
下一步把你要用的那几家中转站或代理服务的检测结果拉出来对一遍，比看宣传语有用得多。→常见问题
是不是反向代理一定比正向代理安全？
不是。它俩防的不是同一件事。反向代理保护的是服务端，对外只暴露一个入口；正向代理服务的是客户端，本身就要经手你的流量。如果你的诉求是隐藏自己身份，用反向代理没有意义；如果诉求是保护后端，用正向代理也搭不起来。先明确要护住哪一头，再谈哪个更安全。
自己搭的正向代理，风险会小一些吗？
自建能减少「陌生人经手你流量」这一层，但不等于没风险：出口 IP 仍是你的，暴露面从代理方转到了你自己的机器和账号上，防护责任也跟着转过来。判断标准是看你能不能自己控制日志、鉴权和使用者范围，控制不了的话，自建只是把风险换了个位置。
代理层改动后怎么确认没引入新问题？
按顺序核三件事：一是来源信息是否正确传递，二是限流与鉴权有没有被绕过，三是异常请求是否还能被记录到。建议先在小流量上验证再全量，改动前后各留一份对照结果。具体指标口径可以到站内 /tools/verify 看探针和评分规则那两节。
