本文档建立了基本的代理术语，并介绍了特定于边缘的代理行为。
内容
代理服务器标识符
代理服务器是用于网络请求的中介。 可以使用代理服务器的地址以及用于与其通信的代理方案来描述代理服务器。
可以使用“PAC 格式”或“URI 格式”将此标识符编写为字符串。
PAC 格式是在代理 自动配置 脚本中命名代理服务器的方式。 例如：
PROXY foo:2138 SOCKS5 foo:1080 DIRECT
“URI 格式”改为将信息编码为 URL。 例如：
foo:2138 http://foo:2138 socks5://foo:1080 direct://
端口号在这两种格式中都是可选的。 如果省略，则使用按方案默认值。
有关 Edge 支持的方案以及如何以 PAC 和 URI 格式编写方案的详细信息，请参阅代理服务器方案部分。
Edge 中的大多数 UI 图面 (包括命令行和策略) 需要 URI 格式的代理服务器标识符。 但是，在 Edge 外部，仅使用地址时，代理服务器的标识精度较低 -- 基于上下文假定代理方案。
在 Windows 的代理设置中，有“HTTP”、“安全”、“FTP”和“SOCKS”代理的主机和端口字段。 除了“SOCKS”之外，这些是不安全的 HTTP 代理服务器的标识符， (代理方案假定为 HTTP) 。
代理解析
Edge 中的代理是在 URL 级别完成的。
当要求浏览器提取 URL 时，它需要决定要将请求发送到哪个 IP 终结点。 这可以是代理服务器，也可以是目标主机。
这称为代理解析。 代理解析的输入是 URL，输出是代理服务器标识符的有序列表。
可以使用以下任一方式描述要使用的代理：
手动代理设置 - 使用声明性规则集定义代理解析。 这些规则表示为从 URL 方案到代理服务器标识符的映射，以及用于何时进行 DIRECT 而不是使用映射代理的代理绕过规则列表。
PAC 脚本 - 使用 JavaScript 程序定义代理解析，每当提取 URL 以获取要使用的代理服务器标识符列表时就会调用该程序。
自动检测 - WPAD 协议用于使用 DHCP/DNS) 探测网络 (，并可能发现 PAC 脚本的 URL。
代理服务器方案
在浏览器中使用显式代理时，网络请求的多个层会受到影响，具体取决于所使用的方案。 代理方案的一些影响包括：
是否通过安全通道与代理通信？ 名称解析 (例如：DNS) 完成客户端还是代理端？ 支持对代理服务器的哪些身份验证方案？ 可以通过代理发送哪些网络流量？ Edge 支持以下代理服务器方案：
DIRECT 代理方案
默认端口：不适用 (主机和端口均不适用) 示例标识符 (PAC) ： DIRECT 示例标识符 (URI) ： direct:// 这是一个伪代理方案，指示我们将请求直接发送到目标服务器，而不是使用代理。
将此称为“代理服务器”并不精确，但它是一种方便的抽象。
HTTP 代理方案
默认端口：80 示例标识符 (PAC) ： PROXY proxy:8080， proxy (非标准;不要使用) 示例标识符 (URI) ： http://proxy:8080， proxy:8080 (可以省略方案) 一般在引用“代理服务器”或“Web 代理”时，它们谈论的是 HTTP 代理。
在 Edge 中使用 HTTP 代理时，名称解析始终延迟到代理。 HTTP 代理可以代理 http://、 https://ws:// 和 wss:// URL。
与 HTTP 代理服务器的通信不安全，这意味着代理 http:// 请求以明文形式发送。 通过 HTTP 代理代理 https:// 代理请求时，TLS 交换使用 CONNECT 方法通过代理转发，因此端到端加密不会中断。 但是，在建立隧道时，目标 URL 的主机名会以明文形式发送到代理服务器。
Edge 中的 HTTP 代理支持与目标服务器相同的 HTTP 身份验证方案：基本、摘要、协商、NTLM。
HTTPS 代理方案
默认端口：443 示例标识符 (PAC) ： HTTPS proxy:8080 示例标识符 (URI) ： https://proxy:8080
这类似于 HTTP 代理，但与代理服务器的通信受 TLS 保护，并且可以协商 HTTP/2 (但 QUIC) 。
由于与代理服务器的连接是安全的， https:// 因此通过代理发送的请求不会像使用 HTTP 代理那样以明文形式发送。 同样，由于 CONNECT 请求是通过受保护的通道发送的，因此也不会显示代理 https:// URL 的主机名。
除了常用的 HTTP 身份验证方法外，HTTPS 代理还支持客户端证书。
使用 HTTP/2 的 HTTPS 代理在 Edge 中可提供比常规 HTTP 代理更好的性能，因为连接限制更高 (Edge 中的 HTTP/1.1 代理限制为跨所有域) 的 32 个同时连接。
Edge、Firefox 和 Opera 支持 HTTPS 代理;但是，大多数较旧的 HTTP 堆栈不会。
无法通过系统代理设置指定 HTTPS 代理。 相反，必须使用 PAC 脚本或边缘代理设置 (命令行、扩展或策略) 。
SOCKSv4 代理方案
默认端口：1080 示例标识符 (PAC) ： SOCKS4 proxy:8080， SOCKS proxy:8080 示例标识符 (URI) ： socks4://proxy:8080 SOCKSv4 是包装 TCP 套接字的简单传输层代理。 它的使用对协议堆栈的其余部分是透明的;在将 TCP 套接字 (连接到代理) 的初始握手后，加载堆栈的其余部分保持不变。
SOCKSv4 不支持代理身份验证方法。
使用 SOCKSv4 代理时，目标主机的名称解析始终在客户端进行，并且必须解析为 IPv4 地址， (SOCKSv4 将目标地址编码为四个八位字节，因此无法) IPv6 目标。
SOCKSv4 的扩展允许代理端名称解析和 IPv6（即 SOCKSv4a）。 但是，Edge 不允许配置或回退到 v4a。
更好的替代方法是仅使用较新版本的协议 SOCKSv5 (它仍然是 20 多年的) 。
SOCKSv5 代理方案
默认端口：1080 示例标识符 (PAC) ： SOCKS5 proxy:8080 示例标识符 (URI) ： socks://proxy:8080， socks5://proxy:8080
SOCKSv5 是包装 TCP 套接字的传输层代理，允许将名称解析延迟到代理。
在 Edge 中，当代理的方案设置为 SOCKSv5 时，即使协议允许客户端和) ，名称解析也始终 (代理端完成。 在 Firefox 客户端与代理端名称解析中，可以使用 配置 network.proxy.socks_remote_dns;Edge 没有等效的选项，并且将始终使用代理端解析。
Edge (中的 SOCKSv5 不支持任何身份验证方法，尽管协议) 确实存在一些身份验证方法。
创建 SOCKSv5 代理的一种便捷方法是使用 ssh -D，它可用于通过 SSH 将 Web 流量隧道传送到远程主机。
在 Edge SOCKSv5 中，仅用于代理基于 TCP 的 URL 请求。 它不能用于中继 UDP 流量。
手动代理设置
配置代理解析的最简单方法是提供一个静态规则列表，其中包括：
URL 方案与代理服务器标识符的映射 代理绕过规则列表 我们将此配置模式称为“手动代理设置”。
手动代理设置可以简洁地描述如下设置：
对所有请求使用代理 http://foo:8080 对所有请求使用代理http://foo:8080（子域请求除外contoso.com）使用代理 对所有https://请求使用代理http://foo:8080，并代理socks5://mysocks:90其他所有请求尽管手动代理设置是跨平台配置代理的一种无处不在的方法，但没有标准表示形式或功能集。
Edge 的手动代理设置最类似于 WinInet 的手动代理设置。 但它也支持来自其他平台的成语，例如 KDE 的反向旁路列表的概念，或 Gnome 将旁路模式解释为后缀匹配。
在 Edge 中定义手动代理设置时，我们指定了三个 (可能为空) 代理服务器标识符列表：
用于 HTTP 的代理 - 用于请求的代理服务器标识符 http:// 列表，如果 HTTPS 的非空代理 -用于请求的代理服务器标识符列表，如果无其他代理，则为代理服务器标识符 https:// 列表 - 要用于其他所有 (与其他两个列表不匹配的代理服务器标识符列表) 有许多方法可以在 Edge () 的其他部分中讨论。
以下示例使用命令行方法。 使用 --proxy-server=XXX (启动 Edge，并选择性地 --proxy-bypass-list=YYY)
示例：若要对所有请求使用代理 http://foo:8080 ，可以使用 启动 Edge --proxy-server="http://foo:8080"。 这表示：
HTTP 的代理 - HTTPS 的空代理 - 空其他代理 - http://foo:8080 使用上述配置，如果代理服务器无法访问，则所有请求都将失败。ERR_PROXY_CONNECTION_FAILED 若要解决此问题，可以通过使用 --proxy-server="http://foo:8080,direct://" 启动来向 DIRECT 添加回退 (记下逗号分隔列表) 。 此命令行表示：
HTTP 的代理 - HTTPS 的空代理 - 空其他代理 - http://foo:8080， direct:// 如果相反，我们希望仅 http:// 通过 HTTPS 代理 https://foo:443代理代理 URL，并让其他所有使用 SOCKSv5 代理 socks5://mysocks:1080 ，可以使用 启动 Edge --proxy-server="http=https://foo:443;socks=socks5://mysocks:1080"。 现在，这将扩展到：
HTTP 的代理 - https://foo:443 HTTPS 的代理 - 空其他代理 - socks5://mysocks:1080 上述命令行使用 WinInet 的代理映射格式，具有一些额外的功能：
可以将 Edge 的 URI 格式用于代理服务器标识符，而不是仅 hostname:port通过 命名代理服务器。 换句话说，你可以为代理方案添加前缀，使其不默认为 HTTP。
映射 socks= 被更广泛地理解为“其他代理”。 后续代理列表可以包含任何方案的代理，但如果省略方案，则它将被理解为 SOCKSv4，而不是 HTTP。
将 WebSocket URL 映射到代理
手动代理设置没有 或 ws://wss:// URL 的映射。
为这些 URL 方案选择代理与其他 URL 方案略有不同。 Edge 使用的算法是：
如果“其他代理”为 nonempty，请使用它 如果“HTTPS 的代理”为非空，请使用它否则使用“HTTP 代理”这是根据 RFC 6455 第 4.1.3 节中的建议。
可以使用 PAC 脚本单独路由 ws:// 和 wss:// 。
手动代理设置中的代理凭据
大多数平台的手动代理设置允许为代理登录指定明文用户名/密码。 Edge 不会实现此功能，并且不会使用代理设置中嵌入的任何凭据。
代理身份验证将改为通过普通流来查找凭据。
代理绕过规则
除了指定三个代理服务器标识符列表外，Edge 的手动代理设置还允许使用 URL 模式指定“代理绕过规则”列表。
此规则集确定给定 URL 是否应一起跳过使用代理，即使为该 URL 定义了代理。
此概念也以“异常列表”、“排除列表”或“无代理列表”等名称而闻名。
代理绕过规则可以编写为字符串的有序列表。 排序通常并不重要，但在使用减法规则时可能会有。
从命令行指定手动代理设置时， --proxy-bypass-list="RULES" 可以使用 开关，其中 RULES 是分号或逗号分隔的绕过规则列表。
有关 Edge 支持代理绕过规则的 URL 模式格式，请参阅代理配置 URL 模式。
使用系统代理设置时，应使用平台的规则格式，而不是 Edge 的规则格式。
代理配置 URL 模式
本部分介绍 Edge 支持在代理配置上下文中指定 URL 模式的字符串构造，例如，代理绕过规则或 DestinationMatchers 策略的值 ProxyOverrideRules 。 从命令行标志、扩展或策略定义 Edge 手动代理设置时，可以使用这些模式。
代理配置 URL 模式：主机名
[ URL_SCHEME "://" ] HOSTNAME_PATTERN [ ":" <port> ]
使用通配符模式以及可选方案和端口限制匹配主机名。
示例：
foobar.com - 匹配任何方案和端口的 URL，其规范化主机为 foobar.com*foobar.com - 匹配任何方案和端口的 URL，其规范化主机以 (结尾 foobar.com ，例如 blahfoobar.com 和 foo.foobar.com) *.org:443 - 使用端口 443 和顶级域 .orghttps://x.*.y.com:99 匹配任何方案的 URL - 匹配 https:// 端口 99 上的 URL，其规范化主机名匹配 x.*.y.com
代理配置 URL 模式：子域
[ URL_SCHEME "://" ] "." HOSTNAME_SUFFIX_PATTERN [ ":" PORT ]
以点开头的主机名模式采用特殊大小写，表示子域匹配。
.foo.com 是编写 *.foo.com的另一种有效方法。
示例：
.contoso.com- 匹配 outlook.contoso.com 和 foo.bar.contoso.com，但不http://.contoso.comcontoso.com匹配 - 仅http://匹配属于 子域的 URLcontoso.com
代理配置 URL 模式：IP 文本
[ SCHEME "://" ] IP_LITERAL [ ":" PORT ]
匹配 IP 地址文本的 URL，以及可选的方案和端口限制。 这是考虑 IP 文本规范化的主机名匹配的特殊情况。 例如，规则 [0:0:0::1] 和 [::1] 是等效的， (都表示) 相同的 IPv6 地址。
示例：
127.0.0.1
http://127.0.0.1
[::1] - 匹配 IPv6 环回地址 [0:0::1] 的任何 URL - 与上述 http://[::1]:99 相同 - 匹配端口 99 上 IPv6 环回的任何 http:// URL
代理配置 URL 模式：IPv4 地址范围
IPV4_LITERAL "/" PREFIX_LENGTH_IN_BITS
匹配主机名为 IPv4 文本且位于给定地址范围之间的任何 URL。
请注意，这仅适用于属于 IP 文本的 URL。
示例：
192.168.1.1/16
代理配置 URL 模式：IPv6 地址范围
IPV6_LITERAL "/" PREFIX_LENGTH_IN_BITS
匹配处于给定范围之间的 IPv6 文本的任何 URL。 IPv6 文本不能用括号括起来。
请注意，这仅适用于属于 IP 文本的 URL。
示例：
fefe:13::abc/33
[fefe::]/40 --错！ IPv6 文本不能用括号括起来
代理配置 URL 模式：简单主机名
<local>
匹配没有句点的主机名，而不是 IP 文本。 这是一个朴素的字符串搜索 ，这意味着出现在任意位置的句点数 (包括尾随点！) 。
此规则对应于 macOS 上的“排除简单主机名”复选框和 Windows 上的“不要将代理服务器用于本地 (Intranet) 地址”。
规则名称来自 WinInet，很容易与 localhost 的概念混淆。 但是，这两个概念是正交的。 实际上，不会添加规则来绕过 localhost，因为它已经隐式完成。
代理配置 URL 模式：减去隐式规则
<-loopback>
减去 localhost 和链接本地地址 (隐式代理绕过规则) 。 只有测试设置才需要此作。 请注意代理 localhost 的安全影响。
虽然常规绕过规则指示浏览器有关不应使用代理的 URL 的信息，但此规则具有相反的效果，并告知浏览器改用代理。
使用减法规则时，排序可能很重要，因为规则将按从左到右的顺序进行评估。
<-loopback>;127.0.0.1 效果 127.0.0.1;<-loopback>与 略有不同。
IP 地址范围绕过规则的含义
手动代理设置中的 IP 地址范围绕过规则仅适用于 URL 文本。 这不是人们本能预料到的。
示例：
假设我们为所有请求配置了代理，但为 192.168.0.0.1/16添加了绕过规则。 如果我们现在导航到 http://foo (在设置中解析为 192.168.1.5) 浏览器直接连接 (绕过代理) ，因为我们指示了包含此 IP 的绕过规则？
它通过代理。
在这种情况下，绕过规则不适用，因为浏览器实际上从未对 foo执行名称解析。 代理解析发生在名称解析之前，根据以后选择的代理方案，客户端名称解析可能永远不会执行。
IP 范围代理绕过规则的用途相当有限，因为它们仅适用于 URL 显式为 IP 文本的请求。
如果需要根据 URL 主机名的已解析 IP 地址做出代理决策，则必须使用 PAC 脚本。
隐式绕过规则
不会通过代理发送对某些主机的请求，而是直接发送。
我们称之为隐式绕过规则。 隐式绕过规则匹配其主机部分为 localhost 名称或链接本地 IP 文本的 URL。 实质上，它匹配：
localhost
*.localhost
[::1]
127.0.0.1/8
169.254/16
[FE80::]/10 完整规则稍微复杂一些。 例如，在 Windows 上，我们还识别 loopback。
隐式代理绕过规则的概念与 Windows 和 macOS (上的平台级代理支持一致，尽管由于它们的实现怪癖而存在一些差异 - 请参阅 net::ProxyHostMatchingRules::MatchesImplicitRules)
为什么首先应用隐式代理绕过规则？ 当然，有关人体工学和用户期望的注意事项，但更大的问题是安全性。 由于 Web 平台将 localhost 视为安全源，因此代理它的能力授予额外的权限。 当代理设置在外部可控制（如使用 PAC 脚本时）时，这尤其成问题。
重写隐式绕过规则
如果希望通过代理发送到 localhost 的流量（尽管存在安全问题），可以通过添加特殊的代理绕过规则 <-loopback>来完成。 此规则具有减去隐式规则的效果。
例如，使用命令行标志启动 Edge：
--proxy-bypass-list="<-loopback>"
使用 PAC 脚本时，目前没有用于禁用隐式代理绕过规则的机制。 代理绕过规则 仅适用于 手动设置，因此此方法不能用于让 PAC 脚本决定 localhost URL 的代理。
内容许可证
注意
本页面的某些部分是根据 Chromium.org 创建和共享的作品所做的修改，并根据 Creative Commons Attribution 4.0 国际许可证中所述的条款进行使用。 可在此处找到原始 Chromium 页面。
本作品根据 Creative Commons Attribution 4.0 International License 获得许可。