macOS 系统代理与应用代理的区别：范围、优先级与排查方法

更新于 2026-10-22 · ghproxy.cyou

简答：macOS 系统代理是系统提供给应用使用的代理信息，应用代理则由具体 App 或按应用工具单独决定。浏览器可能跟随系统代理，Terminal、Git、Telegram、Docker 等程序却可能使用自己的环境变量或独立设置；需要覆盖更多程序时，应检查应用配置或使用具备 TUN/虚拟网卡接管能力的客户端。

定义：macOS 系统代理是“网络”设置中的全局代理配置，应用代理是某个 App、命令行工具或按应用代理软件自己的代理配置，两者不是同一个开关。

先看结论：两种代理到底差在哪里？

如果你只想让支持系统代理的网页应用使用代理，先配置 macOS 的系统代理；如果只有某个 App、Terminal、Git 或 Docker 需要代理，应优先检查该程序自己的代理设置。系统代理不是“所有流量自动经过代理”，它更像是 macOS 向应用公布一组代理参数，应用是否读取、怎样读取，仍由应用实现决定。Apple 官方文档列出了 macOS 可配置的 HTTP、HTTPS、SOCKS、PAC 和绕过规则；Surge 的官方原理说明也明确区分了“配置代理”和“虚拟网卡接管”。

方式	谁控制	主要作用范围	是否要求应用支持	适合场景
macOS 系统代理	macOS 网络设置或代理客户端	使用系统网络框架并遵循系统代理的应用	需要	普通网页浏览、部分图形界面应用
应用内代理	具体 App 自己的设置	通常只影响该 App	不依赖 macOS 系统代理	Telegram、Firefox、单个工具单独走代理
按应用代理工具	代理工具按进程或规则决定	指定 App、域名或进程	取决于工具的接管方式	多应用分流、只让某个程序使用代理
TUN/虚拟网卡模式	网络客户端通过虚拟网卡和路由接管	通常比系统代理覆盖更广，也可能处理部分 UDP	通常不要求 App 主动支持	终端、后台程序或不读取系统代理的应用

四个概念不要混用：系统代理、应用代理、按应用代理与 TUN

1. macOS 系统代理

在 macOS 中，入口通常是“系统设置”→“网络”→选择当前网络服务→“详细信息”→“代理”。这里可以填写自动代理发现、PAC、网页代理（HTTP）、安全网页代理（HTTPS）和 SOCKS 代理，也可以设置不走代理的主机与域名。具体字段和入口以Apple 的 Mac 代理设置文档为准。

2. 应用内代理

应用内代理只由某个应用自己决定。例如 Firefox 的连接设置中既有“使用系统代理设置”，也有“手动代理配置”和 PAC 选项；如果改成手动配置，它就不再等同于 macOS 系统代理。Telegram for macOS 也提供独立的代理入口，因此不能仅凭系统代理已开启，就断定 Telegram 一定按相同方式连接。可分别查看Firefox 官方连接设置说明和Telegram 官方代理说明。

3. 按应用代理

按应用代理是工具层面的说法，重点是“哪个进程、域名或规则使用代理”。它可能通过系统代理、应用配置、环境变量或虚拟网卡实现，不能只看名称判断覆盖范围。遇到某个应用不生效时，先确认它是否有独立代理选项，再看客户端连接记录。

4. TUN/虚拟网卡模式

TUN 通过虚拟网卡和路由接管网络连接，应用通常不需要主动支持代理。Surge 官方中文原理文档将“系统代理接管”和“虚拟网卡接管”列为不同方法：前者要求程序支持代理机制，后者对不支持系统代理的程序更有覆盖能力，但通常需要客户端的服务模式、网络扩展或管理员授权，并可能带来更高的排查复杂度。

macOS 常见应用应该怎么判断？

下面是“先查证、再配置”的判断表。它不是对所有版本和所有发行渠道的永久保证；应用更新、扩展、企业策略和客户端模式都可能改变实际行为。

应用或工具	优先检查什么	判断方法
Safari	macOS 系统代理	Safari 的代理入口会跳转到 macOS 网络设置，参考Safari 官方说明；开启后仍应实际访问目标站点验证。
Firefox	Firefox 自己的连接设置	在 Firefox 设置中确认是“使用系统代理设置”、手动配置、PAC 还是“不使用代理”。
Chrome	浏览器实际使用的代理信息	打开 `chrome://net-export` 或网络日志相关页面查看 Proxy 信息，不要只根据 macOS 开关推断。Google 官方排查文档说明网络日志可查看浏览器正在使用的代理设置。
Terminal / curl	环境变量或命令行参数	系统代理开启不代表 curl 已配置。curl 官方文档说明可使用 `http_proxy`、`HTTPS_PROXY`、`ALL_PROXY`、`NO_PROXY`，也可用 `-x` 或 `--proxy` 临时指定。
Git	Git 配置或环境变量	Git 使用的是 `http.proxy`，而不是单独的 `https.proxy` 开关；HTTPS 地址的 Git 请求同样使用 `http.proxy`。请参考Git 官方 git-config 文档。
Telegram	Telegram 应用内代理	在 Telegram for macOS 的设置中检查 Use Proxy；不要把 Telegram 的独立代理与 macOS 系统代理混为一谈。
Docker Desktop	Docker Desktop 自己的代理设置	Docker 官方文档显示 Docker Desktop 可使用系统代理或手动配置 HTTP、HTTPS、SOCKS5 代理；容器网络还涉及 Docker Desktop 后端进程，因此不能只检查 macOS 系统代理。
App Store 和后台服务	实际连接结果与系统组件设置	未核实具体版本和网络环境下是否统一遵循用户配置的代理，不建议仅凭浏览器结果推断。应结合客户端日志、系统网络状态和实际下载结果判断。

macOS 系统代理的设置与核验步骤

先确认本机代理客户端正在监听。记录客户端显示的 HTTP、HTTPS 或 SOCKS 监听地址与端口。若客户端要求填本机地址，通常应使用 127.0.0.1，不要把远程节点地址直接当作 macOS 系统代理地址。
打开 macOS 代理入口。进入“系统设置”→“网络”→当前网络服务→“详细信息”→“代理”，按客户端实际提供的协议填写对应类型。PAC、HTTP、HTTPS、SOCKS 不是同一个协议字段，不能随意混填。字段定义以Apple 官方文档为准。
只保留一套明确的代理来源。如果同时开启系统代理、Firefox 手动代理、Terminal 环境变量和 TUN，出现“浏览器能用、命令行不能用”或“关闭客户端后仍无法联网”并不奇怪。排查时先关闭应用内代理和环境变量，再只测试系统代理；随后再逐项恢复。
用命令确认系统代理状态。在 Terminal 执行：

scutil --proxy

该命令用于查看 macOS 当前系统代理相关状态。若需要检查 curl 是否受到环境变量影响，可执行：

env | grep -i proxy

若变量为空，再用显式代理参数进行对照测试；curl 的 -x 参数会覆盖已有代理环境变量，具体行为参见curl 官方手册。

分别验证浏览器和命令行。先在浏览器访问一个你信任的 IP 查询页面，再用 curl 请求同一测试地址。两者结果不一致时，优先判断为代理范围或配置来源不同，而不是立刻判断节点故障。
检查绕过规则。macOS 的“不包括简单主机名”和“忽略这些主机与域的代理设置”可能使某些地址直连。内网域名、局域网地址和企业服务尤其要检查排除项。

Git、curl 和 Docker 为什么经常与系统代理不一致？

curl：curl 会读取代理环境变量，也可以通过 -x 或 --proxy 明确指定；因此“Safari 能打开”并不等于当前 Terminal 中的 curl 已经走相同代理。可用下面的方式查看当前 shell 是否存在代理变量：

env | grep -i proxy

Git：不要查找或删除不存在的 https.proxy 配置项。Git 的官方配置字段是 http.proxy，它可以覆盖通常来自 http_proxy、https_proxy 和 all_proxy 的代理设置。可执行：

git config --global --get http.proxy

如需删除全局 Git 代理：

git config --global --unset http.proxy

如果还配置过具体远程仓库代理，应继续检查对应的 remote.<name>.proxy，而不是凭 macOS 系统代理状态判断。

Docker Desktop：Docker Desktop 有自己的代理配置入口，并且容器流量由 Docker Desktop 后端处理。根据Docker 官方网络文档，可以在设置中选择使用系统代理或手动填写 HTTP、HTTPS、SOCKS5 代理。因此宿主机浏览器正常，不足以证明容器内拉取镜像、访问仓库或执行构建时也能使用相同代理。

同时开启多种代理时，按这个顺序排查

确认目标：你要解决的是浏览器、某一个 App、命令行、容器，还是尽量覆盖本机更多连接？目标不同，选择的代理层级不同。
关闭重复来源：暂时关闭应用内手动代理、Terminal 中的 http_proxy 等环境变量，以及客户端的 TUN/增强模式，只保留系统代理测试。
确认客户端监听：检查本机监听地址和端口是否存在，客户端日志中是否出现请求。
分层测试：先测 Safari 或 Chrome，再测 curl，再测目标 App。某一层失败后不要继续修改下一层配置。
再启用 TUN：如果命令行、Docker 或某个程序不读取系统代理，可在确认客户端支持和权限条件后启用 TUN。启用后要重新检查路由、DNS、应用内代理和系统代理是否形成回环。
恢复默认：排查结束后关闭不需要的代理环境变量和系统代理，避免客户端退出后应用仍尝试连接已经不存在的本地端口。

注意，HTTP、HTTPS、SOCKS5 是代理协议或连接方式，系统代理、应用代理和 TUN 是接管层级；它们不能简单画等号。系统代理也不等于所有 UDP、后台服务和系统进程都被覆盖。需要更广覆盖时，应依赖客户端明确提供的 TUN 或其他系统级网络扩展能力。

安全与兼容性提醒

不要把代理账号、密码或带认证信息的完整代理 URL 粘贴到公开日志、截图或工单中。
安装未知客户端、网络扩展或证书前，先确认来源和用途。HTTPS 解密类功能可能要求安装根证书；没有明确需求时不要随意安装。
Apple Silicon 与 Intel 客户端是否兼容，取决于具体客户端版本、架构和网络扩展支持，未核实的信息不要仅凭芯片型号判断。
如果关闭客户端后仍然无法联网，优先执行 scutil --proxy、env | grep -i proxy，再检查 Git、Firefox、Telegram 或 Docker 的独立配置。

一句话选择建议

普通网页浏览先试 macOS 系统代理；只有一个 App 需要代理时优先用应用内代理；Terminal、Git 或 Docker 不生效时检查各自配置；需要覆盖不支持系统代理的程序时，再考虑具备 TUN/虚拟网卡接管能力的客户端，并按权限、DNS、路由和日志逐层验证。

本文是第三方使用指南站，相关应用和系统设置会因版本、发行渠道及网络环境变化；具体字段和权限应以对应产品的官方文档为准。

常见问题

macOS 开启系统代理后，所有 App 都会走代理吗？

不会。系统代理只是向应用提供代理配置，应用需要主动读取并支持对应协议。浏览器、命令行工具、后台服务和容器可能分别使用系统设置、环境变量、独立配置或 TUN，因此必须逐个验证。

为什么 Safari 能用代理，Terminal 里的 curl 却不能？

Safari 可通过 macOS 的网络代理设置工作，而 curl 主要读取 http_proxy、HTTPS_PROXY、ALL_PROXY 等环境变量，或使用 -x/--proxy 参数。先执行 env | grep -i proxy，再用显式 -x 参数做对照测试。

Git 应该配置 http.proxy 还是 https.proxy？

配置 http.proxy。Git 官方配置字段是 http.proxy；即使远程仓库地址使用 HTTPS，Git 的相关请求也使用这个代理配置。不要把不存在的 https.proxy 当作第二个独立开关。

Telegram 为什么要单独设置代理？

Telegram for macOS 提供自己的代理设置，因此它可能使用应用内代理，而不是完全依赖 macOS 系统代理。应在 Telegram 设置中查看 Use Proxy，并结合连接状态验证。

什么时候应该使用 TUN，而不是系统代理？

当目标程序不读取系统代理、命令行或后台服务始终直连，且客户端明确支持 TUN/虚拟网卡时，可以考虑 TUN。启用前要确认权限、网络扩展、DNS 和路由配置，避免与已有系统代理或应用代理互相覆盖。

参考资料

在 Mac 上更改代理设置 - 官方 Apple 支持
在 Mac 上使用 Safari 浏览器设置代理服务器 - 官方 Apple 支持
Connection settings in Firefox - Firefox Help
Telegram MTProxy - Telegram 官方文档（core.telegram.org）
Surge 官方中文指引：理解 Surge 原理（manual.nssurge.com）
curl 官方命令手册：--proxy 与代理环境变量（curl.se）
Git 官方 git-config 文档（git-scm.com）
Docker Desktop 官方网络配置文档
Troubleshoot Chrome network issues - Chrome Enterprise and Education Help