一句话：HTTP Proxy 就是一台站在“你的浏览器”和“目标网站”之间的中转服务器。浏览器不再自己直连网站，而是先把请求交给代理，再由代理替它连接目标。

例如 Windows A 已经连接公司 VPN，PC B 自己没有这个 VPN，但 PC B 只需要浏览器访问公司内部 Web 系统。

NetConfiger HTTP 与 SOCKS5 服务界面示意这是代理服务界面示意。图中的 IP 和端口只是示例，实际部署以软件当前配置为准。
PC B：Chrome / Edge
↓
HTTP Proxy：192.168.1.100:PORT
↓
Windows A / NetConfiger
↓
Windows A 已连接的 VPN
↓
公司 Web 系统

PC B 的浏览器实际上只需要知道一件事：“以后网页请求先送到 192.168.1.100:PORT。”

至于 Windows A 后面是普通宽带、公司 VPN、SoftEther 还是其他网络出口，是代理服务器那一侧的事情。

下文示例里的 PORT 和 SOCKS_PORT 表示你实际配置的监听端口，不代表产品端口被写死。

普通 HTTP 网页经过代理时，到底发生了什么

HTTP 本身是一个应用层协议。浏览器访问普通 HTTP 网站时，原本会直接连目标服务器，然后发送类似：

GET /index.html HTTP/1.1

用了 HTTP Proxy 后，浏览器先连接代理服务器。代理收到浏览器想访问的目标，再替浏览器发出请求，把服务器返回的数据再交还给浏览器。

通俗理解：
你本来想自己去某个仓库拿东西。现在改成先把“仓库地址 + 要拿什么”告诉中间人，中间人替你去，再把结果送回来。HTTP Proxy 就是这个中间人。

关于 HTTP 的正式语义，可以参考 RFC 9110。RFC 9110 将 HTTP 定义为应用层协议。

最容易让人糊涂的问题：HTTPS 是加密的，HTTP Proxy 怎么代理？

这是理解 HTTP Proxy 最关键的一步。

访问 HTTPS 网站时，浏览器不能像普通 HTTP 那样把加密后的网页内容交给代理“看懂再转发”。常见做法是使用 HTTP 的 CONNECT 方法。

浏览器会对代理说：

CONNECT example.com:443

意思不是“替我读取 example.com 的网页”，而是：

“请帮我和 example.com 的 443 端口打通一条双向通道。”

代理如果同意，就连接目标服务器，然后在两边之间转发字节。之后浏览器和网站之间的 TLS/HTTPS 加密仍然在这条通道里进行。

浏览器
↓ CONNECT example.com:443
HTTP Proxy
↓ 建立 TCP 连接
example.com:443
↕
TLS / HTTPS 数据在隧道中双向传输

MDN 对 CONNECT 的定义非常直接：它请求代理建立到目标服务器的隧道，成功后代理在两个方向上转发数据。

所以“HTTP Proxy 只能代理网页”并不是严格的技术描述。
普通 HTTP Proxy 最自然的用途确实是 HTTP/HTTPS，但 CONNECT 建立的是 TCP 隧道。从技术上说，它可以承载不止网页的数据；只是客户端是否会这么用、代理是否允许目标端口，都取决于具体软件和代理策略。

那为什么我们仍然说 HTTP Proxy “更偏网页”

因为技术能力和现实使用方式不是一回事。

大多数浏览器、Web 工具、办公系统、HTTP API 客户端对 HTTP Proxy 支持最成熟。Windows、浏览器和很多企业软件也长期使用 HTTP/HTTPS Proxy 作为 Web 出口控制方式。

而很多非 Web 程序并不会自动把自己的任意 TCP/UDP 连接交给 HTTP Proxy。

使用场景HTTP Proxy 是否自然原因
Chrome / Edge 打网页非常自然HTTP/HTTPS 就是浏览器核心协议
ERP / OA / CRM 网页后台自然本质仍是 Web 应用
REST API / Web API通常自然仍是 HTTP/HTTPS
SSH / 数据库 TCP不一定需要客户端主动支持 HTTP CONNECT 或其他代理机制
通用 UDP不自然传统 HTTP Proxy 不是通用 UDP 转发协议

所以“HTTP Proxy 更偏网页/Web”是一个很好用的通俗总结，但它背后真正的技术原因是：HTTP Proxy 的协议模型、客户端支持和部署习惯都围绕 HTTP/HTTPS。

“IP + 端口”到底是什么

很多小白真正卡住的其实不是 HTTP，而是：

192.168.1.100:PORT

这两个数字到底代表什么？

部分含义
192.168.1.100代理服务器所在电脑的网络地址。也就是“我要先把请求送到哪台电脑”。
PORT这台电脑上 HTTP Proxy 服务正在监听的端口。可以理解成“这台电脑上的哪一个网络服务入口”。

所以填写代理并不是在告诉浏览器“你要访问哪个网站”。而是在告诉浏览器：

“以后访问网站之前，先去找 192.168.1.100 这台电脑上的 PORT 服务。”

HTTP Proxy 会让整台电脑都走代理吗？

不会自动做到。

这是很多用户第一次使用代理时最大的误解。

你给 Chrome 配了 HTTP Proxy，只能证明 Chrome 会把支持的网络请求交给代理。

同一台 PC 上的：

微信、Windows Update、某个游戏、数据库程序、自己写的软件……是否也走这个代理，要看它们是否读取相同的代理设置、是否支持 HTTP Proxy，或者有没有系统级转发机制接管它们。

Windows“系统代理”也不是“系统所有流量代理”。
它更像是 Windows 提供的一套代理配置，只有愿意读取并遵守这些设置的软件才会使用。它不是默认路由，也不是透明网关。

如果你真正需要的是“整台电脑不管运行什么软件，都默认把外部流量交给另一台 Windows”，那已经是网关、路由、NAT、TUN 等问题。

如果你发现浏览器已经通过代理访问成功，但同一台电脑上的其他程序还是走原来的网络，这通常不是“代理失效”，而是应用代理和系统路由本来就不是一回事。《代理、VPN、网关到底有什么区别？为什么浏览器走了 VPN，其他软件却没有》 专门解释这个问题。

HTTP Proxy 和 SOCKS5 到底怎么选

到这里其实已经很好判断。

情况更自然的选择
浏览器、网页、Web 后台、HTTP APIHTTP Proxy 通常最直接
软件明确只提供 HTTP ProxyHTTP Proxy
软件需要建立更通用的 TCP 连接，而且明确支持 SOCKS5SOCKS5
需要 SOCKS5 UDP 且客户端/服务端都支持SOCKS5
设备完全没有代理设置，却要求整机全部走另一条网络两个都不是完整答案，应该看网关/TUN/NAT

如果软件不是以网页访问为主，而是需要建立更通用的网络连接，就会经常碰到 SOCKS5。《SOCKS5 是什么？从“它能代理什么”到 TCP、UDP、DNS 一次讲明白》 里把它为什么更通用、UDP 和 DNS 又是怎么回事单独展开了。

放回 NetConfiger 的实际使用场景

Windows A 已经连接客户公司的 VPN，本机可以打开内部 OA。

PC B 不安装 VPN，只需要 Chrome 访问 OA。

NetConfiger 在 Windows A 上开启：

HTTP 192.168.1.100:PORT

PC B 的 Chrome 使用这个代理后，路径变成：

PC B Chrome
↓
192.168.1.100:PORT
↓
Windows A
↓
公司 VPN
↓
内部 OA

这时候你甚至不需要知道 CONNECT 的报文长什么样，就能正确使用。

但当出现“HTTPS 为什么还能打开”“为什么浏览器能用而微信不能用”“为什么数据库工具不认 HTTP Proxy”时，上面的专业原理就能解释清楚原因。

最终记住：HTTP Proxy 不是“给整台电脑换网络”，而是让支持它的软件把 HTTP/HTTPS 等连接交给一个中间代理。HTTPS 常通过 CONNECT 建 TCP 隧道，所以“HTTP Proxy = 只能传普通网页”也不准确。

放到 NetConfiger 的实际场景里，HTTP Proxy 最适合解释这样一件事：Windows A 已经有一条可用网络，PC B 的浏览器不需要重新建立同样的 VPN，只要把 HTTP 请求交给 Windows A 上的代理服务，就能复用那条现有网络。

核心要点

  • HTTP Proxy 让支持代理的应用先连接代理服务器；HTTPS 常通过 CONNECT 建立 TCP 隧道。
  • 浏览器或系统代理设置不等于整台 Windows 的所有流量都会经过代理。
  • 实际部署时只需要记住主机地址和已配置的监听端口，并用目标应用验证真实路径。