代理与负载均衡

12.1先从一个例子理解概念

你不直接找目标取内容，而是让中间服务替你去取；另一端也可能在入口把请求分给多台机器。这些场景需要分清代表谁、决定什么。

替哪一方工作：正向与反向代理

正向代理代表客户端访问目标；反向代理代表服务端接收请求，再交给内部服务。分类看它代表哪一方，不是简单看箭头朝左还是朝右。

应用不用显式指定：透明处理

透明代理等处理方式可通过路由或过滤接住应用流量，使应用无需显式指定代理。是否发生及最终出口，要看实际路径和配置。

把工作分给多个后端：负载均衡

负载均衡是在多台服务端之间分配连接或请求；这些被分配的服务器叫后端。不是看到多个端口就证明存在均衡器，也不是必定平均分。

按什么信息分配：L4与L7

L4借用OSI第4层号，常指按传输地址/端口等分配；L7借用第7层号，指理解应用内容后决策，比如按网页路径分配。这些层号表达决策范围，不直接保证性能。

把内容放到不同地点：CDN

CDN（内容分发网络）把内容和服务分布到多个位置，通过缓存与调度改善访问。缓存命中表示可复用已存内容，具体节点选择不只靠DNS一种方式。

下面再用这些概念看原理、命令和结果。规范与官方资料列在本章末尾，类比只帮助理解，不代替协议规则。

12.2代理能解决什么问题

代理就是"中间人"—— 你让它去替你取东西。它有几种典型用途：

注意：代理和 NAT 是两件事。 NAT 在网络层改地址（用户完全无感），代理在应用层替你去请求（可能感知得到）。本机两个都装了 —— 后面会看到。

12.3正向代理与反向代理

这是代理最重要的一个分类。

一句话区分：正向代理知道"我是替客户端去的"，反向代理知道"我是替服务器接的"。

12.4实测：本机有三套代理配置，且它们可以因应用范围不同而采用不同配置

这是本章最有意思的一个发现。查三个不同的地方：

第一层：环境变量

http_proxy   = http://127.0.0.1:7897
https_proxy  = http://127.0.0.1:7897
all_proxy    = http://127.0.0.1:7897

谁读这个：命令行工具（curl、wget、很多语言的 HTTP 库）。《应用层》模块实测过 —— curl -v 的输出里明确写着 Uses proxy env variable https_proxy。

第二层：WinHTTP（系统级）

netsh winhttp show proxy
→ Current WinHTTP proxy settings: Direct access (no proxy server).

谁读这个：Windows 服务、以及使用 WinHTTP API 的程序。

第三层：WinINET（IE / Edge 用的，存在注册表里）

ProxyEnable   = 1
ProxyServer   = 127.0.0.1:7890
ProxyOverride = ;localhost.*;;*zhihu.com;*zhimg.com;*jd.com;…

谁读这个：Internet Explorer、Edge、以及很多"跟随系统设置"的 GUI 程序。

三套配置对照

三个地方，两个不同的端口，一个没有显式代理配置。

再对照本机实际监听的两个代理进程：

127.0.0.1:7890   FlClashCore
127.0.0.1:7897   verge-mihomo
127.0.0.1:1053   verge-mihomo

7890 是 FlClash，7897 是另一个代理软件（verge-mihomo）。这台机器上同时装了两个代理程序，各自占一个端口，而且配置分别指向了不同的那一个。

12.5透明代理与 TUN：不配置也能被接管

《链路层和局域网》模块实测过一个反直觉的现象：向 192.0.2.1:9999（一个永不路由的保留地址）发连接，0.6 毫秒就"成功"了。

原因就在这张网卡：

FlClash    198.18.0.1/30     ← 代理软件建的 TUN 虚拟网卡

证据链（都在前面的模块实测过）：

这些历史记录与TUN接管部分流量相容。 Find-NetRoute选择该接口是观察；具体度量、代理代答机制及每条连接出口需要配置、日志或抓包，不由空字段和保留地址一次连接单独证明。

这叫透明代理 —— 从程序的角度看，它只是在正常地 connect() 一个地址，完全不知道中间有个代理。

12.6负载均衡：一台服务器扛不住怎么办

问题：一个网站有几百万用户，一台服务器无论如何都扛不住。

办法：后面放很多台服务器，前面放一个"调度员"把请求分下去。这个调度员就是负载均衡器。

对外它只有一个地址，用户不知道背后有多少台机器 —— 所以负载均衡通常是反向代理。

L4 与 L7：两种层次的负载均衡

这个区分正好接上了《全景与基础》模块讲过的"分层"：

常见的调度算法

还有一个必须做的事：健康检查。 负载均衡器要定期探测后端服务器，发现某台挂了就不再往它那里分发。没有健康检查的负载均衡，会把请求送给已经死掉的服务器 —— 用户看到的就是 502（《应用层》模块讲过 502 是"连不上后面的服务器"）。

12.7实测：别把"多个端口监听"当成负载均衡

历史实测记录有几个 node 进程在监听端口：

127.0.0.1:3201   node
127.0.0.1:5173   node
127.0.0.1:5174   node

这不是负载均衡。 它们是三个不同项目各自的开发服务器（本教程所在的站点就跑在 5174）。

判断依据：历史进程用途与提供内容显示它们是不同开发服务；仅监听127.0.0.1不能排除本机负载均衡。常见对外服务的负载均衡部署会；内部负载均衡也可以只监听私网或本机地址：

• 监听在对外地址上
• 后面挂着多台提供相同服务的服务器
• 有健康检查机制

12.8CDN：地理维度的负载均衡

CDN（内容分发网络）可以理解成"把负载均衡做到地理维度"：

把内容缓存在离用户最近的节点上
  → 用户从就近节点取，不用回源
  → 延迟低、源站压力小

用户怎么被引导到最近的节点？ 可使用地理/策略DNS、Anycast及应用层调度等机制；并非只靠DNS：解析同一个域名时，DNS 根据你的来源返回离你最近的那个节点的 IP。

12.9常见误解

误解一："系统里只有一个代理设置"

历史实测记录至少有三个（环境变量、WinINET、WinHTTP），而且可以互相矛盾 —— 本机就是环境变量指向 7897、WinINET 指向 7890、WinHTTP 说直连。这就是"有的程序走代理、有的不走"的根本原因。

误解二："没配代理就不会走代理"

透明代理不需要配置。 历史实测记录：TUN接口被历史选路结果选中，具体连接是否代答以及最终出口仍需确认（《全景与基础》模块那个"连保留地址也能成功"的实验就是证据）。

误解三："正向代理和反向代理只是方向不同"

本质区别是"替谁办事"：正向代理代表客户端（客户端知道自己配了代理），反向代理代表服务器（客户端以为在直连）。

误解四："负载均衡就是平均分配"

不只是"平均"。实际会用加权（配置高的多分）、最少连接（看实时负载）、一致性哈希（让同一用户固定落在同一台，提高缓存命中率）。而且健康检查比调度算法更重要 —— 没有它，均衡器会一直往挂掉的服务器分发请求。

误解五："多个端口在监听就是集群或负载均衡"

历史实测记录那几个 node 端口是不同项目各自的开发服务器。判断标准是"它们是否提供相同的服务、前面有没有统一入口"，而不是"端口多不多"。

12.10本章小结

12.11自测题

12.12参考资料与适用范围

• RFC 9110 §9、§15：方法幂等性和状态码语义
• Mihomo官方路由规则：连接出口选择
• Microsoft：TCP/IP通信排错指南

修订核对日期：2026-10-13。规则按所列协议与实现范围理解；文中的原始命令输出是历史观察，不表示本次重新实测。跨版本、代理/隧道及不同捕获位置需要另行核对。