正向代理

正向代理代表客户端访问目标。客户端先决定某次连接或请求是否交给代理，再由代理按目标和策略转发。配置了一个代理地址，不意味着所有程序、DNS、UDP或系统流量自动经过它。

理解代理路径时要同时追踪三个问题：谁选择代理，谁解析目标域名，以及每一段是否加密。只看最后目标IP或一个浏览器“代理已连接”提示，无法回答这些问题。

HTTP 请求代理与 CONNECT

向普通HTTP代理请求明文站点时，请求目标通常形如GET http://example.com/index.html HTTP/1.1；代理能读取和处理HTTP。访问HTTPS目标时，客户端常先发送CONNECT example.com:443 HTTP/1.1及相应Host，收到成功2xx后，在隧道中与目标进行TLS握手。

CONNECT成功后的字节不再按该请求的普通HTTP消息体解析。通常客户端到代理、代理到目标是两条独立TCP连接；代理拼接的是字节传输能力，不是把一条TCP连接原封不动延长到服务器。

CONNECT本身不提供加密，也不只限HTTPS。代理可以限制目标端口和目的地，客户端不能把成功连接代理等同于允许访问任何地址。代理认证失败通常对应407与Proxy-Authenticate，目标服务认证的401是另一层。RFC 9110：CONNECT

HTTPS 代理与 HTTPS 目标是两件事

http://proxy.example:8080和https://proxy.example:8443描述客户端到代理的传输方式；目标URL的https://描述目标服务使用TLS。HTTPS代理上再CONNECT到HTTPS目标，可以形成外层代理TLS与内层目标TLS，两者认证对象不同。

不终止内层TLS的代理看不到目标HTTP内容，但仍知道显式CONNECT目标、时间和流量规模。ECH可改变内层ClientHello的可见内容，却不会抹去已发给该代理的CONNECT目标。若客户端信任代理签发的替代证书并允许TLS检查，则实际身份与保密边界已经改变。

HTTP/2、HTTP/3也可承载相应CONNECT机制，不能把所有代理连接都假设为一个HTTP/1.1连接只建一个隧道。普通CONNECT的TCP字节隧道与CONNECT-UDP是不同能力；后者有专门的UDP代理协议约定。RFC 9298

SOCKS5：方法选择、认证与命令不能混作 TCP 握手

首先建立到代理的TCP连接，再协商可用认证方法；选择用户名/密码等方法时还有子协商，之后发送CONNECT、BIND或UDP ASSOCIATE命令。不能把这些阶段统称为固定“三次握手”。

域名地址包含1 B长度与名称字节，没有末尾NUL；端口用2 B网络序。CONNECT回复的BND.ADDR/PORT是代理对目标连接使用的绑定端点，不是把DST原样回显。RFC 1928

用户名密码子协商自己的版本字段为1，不能写成SOCKS主协议版本5。该方法直接传输凭据字节，不自动提供加密；安全性取决于外层传输和部署边界。RFC 1929

完整地址算例：域名 CONNECT 与 IPv4 UDP 头

import ipaddress

name = b'example.com'
request = bytes([5, 1, 0, 3, len(name)]) + name + (443).to_bytes(2, 'big')
assert request.hex() == '050100030b6578616d706c652e636f6d01bb'
assert len(request) == 18
n = request[4]
assert request[5:5+n].decode('ascii') == 'example.com'
assert int.from_bytes(request[5+n:7+n], 'big') == 443
# 无SOCKS分片，IPv4目标。这里DATA只是教学字节，不是实际DNS报文。
udp_head = bytes([0, 0, 0, 1]) + ipaddress.ip_address('192.0.2.53').packed + (53).to_bytes(2, 'big')
packet = udp_head + b'DATA'
assert len(udp_head) == 10 and len(packet) == 14
assert udp_head.hex() == '00000001c00002350035'
assert int.from_bytes(packet[8:10], 'big') == 53
print('CONNECT 请求 / UDP封装头:', len(request), len(udp_head))

该算例只检查编码，不实现代理连接、认证或中继。SOCKS5不提供通用IP层转发，例如ICMP不是直接通过CONNECT发送的TCP内容。

UDP ASSOCIATE：控制连接不是 UDP-over-TCP

客户端通过TCP命令建立关联，命令中的地址端口描述预计使用的客户端UDP端点，未知时可填零。代理回复可用relay端点，客户端随后把每个UDP数据报加SOCKS头发给relay，头中再指定实际目标；不要把关联请求的零地址当每个数据报的最终目的地。

返回数据同样由relay加SOCKS头发给客户端，用于标识远端来源。关联在TCP控制连接关闭时终止；UDP仍可能丢失、重排，TCP控制通道没有替它重传。FRAG=0表示未分片，SOCKS层分片支持可选，不支持的实现丢弃非零FRAG报文；这也不同于IP分片。

IPv4目标的SOCKS UDP头为10 B，IPv6目标为22 B，域名目标为7+名称字节数，再加外层UDP/IP开销。TCP代理能连通不证明UDP relay可达，客户端应用也可能根本不实现UDP ASSOCIATE。

DNS 在哪一侧：地址类型与客户端实现共同决定

客户端先本地解析并发送IP时，代理无法替它撤销已经发生的本地DNS查询。发送ATYP=域名时，则交给代理侧按自己的策略解析或路由；不代表代理必定使用某个固定公共DNS。

curl区分socks5://的本地解析与socks5h://的代理侧解析。以下仅供具备对应本地代理时手动观察，执行会发起真实目标请求：

curl --proxy socks5h://127.0.0.1:1080 --connect-timeout 5 https://example.com/

--connect-timeout也不是整个下载的总时限。代理主机本身的发现、应用预解析、DoH以及其他未使用此代理的进程仍需分别检查；不能只凭一条curl成功就断言整个系统没有本地DNS流量。curl代理选项

把域名改成IP，改变的不只是报文长度

两条路径最终都可以访问同一目标，但代理接收到的证据不同：IP路径没有原域名，域名路径则有长度字节和名称本身。这里展示一次命令的责任边界，不据此宣布系统所有DNS都经过代理。

PAC：按目标选路线，DIRECT 是显式回退

PAC的FindProxyForURL返回代理候选字符串。它是受限环境中的JavaScript，不是可任意访问浏览器页面状态的普通脚本。域名规则常比调用DNS辅助函数更容易预测；isInNet等可能引发本地解析，恰好与希望避免本地解析的意图冲突。

function FindProxyForURL(url, host) {
    // 只把明确受控的内部域名交给直连，不按国家后缀猜服务器位置。
    host = host.toLowerCase();
    if (host === 'intranet.example' || host.slice(-17) === '.intranet.example') {
        return 'DIRECT';
    }
    return 'PROXY 127.0.0.1:7890; SOCKS5 127.0.0.1:1080';
}

实现所支持的PAC语法和辅助函数需按客户端核实。示例最后没有DIRECT，意味着没有明确允许“代理失败就直接访问”的候选。若追加DIRECT，就是改变了失败时的出口策略，不能把它当无害的固定模板。

PAC并不保证每次请求都完整重执行，也不能假设HTTPS URL始终包含路径。以Chromium为例，PAC可见URL有隐私裁剪、代理选择有缓存和失败处理；它的SOCKS5实现也有自己的能力范围。域名后缀.cn不证明目标物理位置，.local还涉及本地名称解析语义，不宜拿来粗略代表全部内网。Chromium代理说明

定位失败：按阶段记录证据

系统代理、环境变量、应用内配置可能互不覆盖；代理链里也可能有不同认证和解析位置。把路线和错误阶段分开，才能避免“所有问题都换一个DNS”或“所有流量都已经被接管”的误判。

继续查阅

• 透明代理与 TUN：应用无显式代理配置时如何接管流量。
• 代理协议对比：按承载和安全边界比较方案。
• 反向代理：服务端入口与连接边界。