---
title: 一次关于 Docker Desktop 与网络代理冲突的深度排查
publishDate: 2025-06-23 19:31:00
excerpt: 软件的自动化行为往往是默认设置 + 环境状态 +历史行为的函数，只有追踪到底层的“注入时机”与“读取路径”，才能真正控制它。
featuredImage: /uploads/屏幕截图-2025-06-24-193700.png
tags:
  - 计算机
---
起初只是一个很常见的错误：

```bash
docker pull redis:7-alpine
Error response from daemon: failed to do request: Head "https://...": proxyconnect tcp: dial tcp 127.0.0.1:7890: connect: connection refused
```

熟悉的 127.0.0.1:7890，这显然是 Clash for Windows 设置的本地代理端口，但我清楚地知道 —— 当时 Clash 并没有开启该代理，甚至我在各类配置中已经明确 **关闭了代理**。

于是我开始了这场探索。

- - -

我做的第一件事，是从最显而易见的路径排查：

* 检查了 Docker Desktop 的 GUI 设置中的 **Settings → Resources → Proxies**，HTTP 和 HTTPS Proxy 字段确实清空；
* 查看了 `~/.docker/config.json`、`/etc/docker/daemon.json`，文件不存在或未设置代理；
* 清理了 Linux 系统中的 `/etc/systemd/system/docker.service.d/http-proxy.conf`；
* 重启 Docker Desktop 与 WSL；
* 查询系统环境变量 `HTTP_PROXY`，无；
* 执行 `netsh winhttp show proxy`，显示为「直接访问」；
* 在 `%APPDATA%\Docker\settings.json` 中设置 `"ProxyHTTPMode": "manual"` 并清空 `OverrideProxyHTTP` 字段。

**一切都「清空」了，但 Docker 依旧在注入 127.0.0.1:7890。**

我开始怀疑是不是 Docker 的代理注入逻辑还有其它通道。

- - -

中途尝试使用 host.docker.internal 代替 127.0.0.1，并通过 No Proxy 配置绕过镜像仓库，也做过一定效果测试，但始终发现一个现象：

只要 Docker 一启动，它就会在 `docker info` 中自动显示：

```bash
HTTP Proxy: http://127.0.0.1:7890
```

而这发生的前提是 —— 我的 Clash 曾打开过系统代理（即开启 System Proxy 开关）。尽管我后来关闭了它，甚至从 Windows 设置中关闭了系统代理设置，但似乎 Docker Desktop 已“记住”了这个地址，并强行注入进来。

这很可能与 Windows 系统中的 WinINET 注册表代理设置有关，而 Docker Desktop 的守护进程则会在启动时默认读取并应用它。

- - -

我意识到这是一个系统性的“注入幽灵代理”问题。于是我去 GitHub 上查找是否有类似的 issue，果然找到了：

* **[Issue #14818](https://github.com/docker/for-win/issues/14818)**：有用户提出 Docker Desktop 会在 GUI 设置空白、系统代理关闭的情况下依旧注入 127.0.0.1 代理，导致拉镜像失败；
* 官方的回应是：“你可能只是没关闭系统代理，去 Windows 设置里关一下。”

我尝试了他的方法 —— 并非在 Clash 中关闭 System Proxy，而是进入 **Windows 设置 → 网络和 Internet → 代理**，关闭“使用代理服务器”这一项。

紧接着，我并没有完全退出 Docker Desktop， 直接**Restart**

这次不同了。Docker 不再注入代理了。

- - -

这让我意识到两个关键点：

1. Docker Desktop 并不是实时读取当前代理，而是**在启动时一次性读取系统代理配置**（可能是注册表 `ProxyServer` 键）；
2. 如果你在启动前系统代理是开启的，那么它就会将当时的代理地址注入进来，即使你之后关闭也无效（即使我在clash处关闭代理并重启。）；
3. 但如果你在**启动后**关闭系统代理（必须在windows处关闭），然后点击 “Restart Docker”，它会重新读取代理配置，此时就能“解除注入”。

- - -

相比我早期尝试的更激进的方式：

* 修改 settings.json；
* 彻底关闭 Docker Desktop；
* 用脚本清理代理路径；
* 重启 WSL；

这个方法更直接、更温和、更可靠。

- - -

回望这次排查，整个问题的根因可以归结为：

> **Docker Desktop 在 Windows 环境下，缺乏一个显式的选项来关闭系统代理注入机制。**

而一旦你的系统曾打开过代理，Docker 就会执念地将其注入进 daemon 环境，哪怕你后来已经关闭它。

最终，我在 GitHub 上对该 issue 作出评论反馈，感谢了官方的建议，并提出了一个请求：

> 是否可以在 future version 中提供 GUI 开关或设置项，彻底控制 proxy 注入。

- - -

> 软件的自动化行为往往是**默认设置 + 环境状态 +历史行为的函数**，只有追踪到底层的“注入时机”与“读取路径”，才能真正控制它。

- - -

我最后退而求其次地采用了“需要时关闭系统代理 + Restart Docker”的方式作为稳定解决方案。

不是理想，但足够实用。

我仍然期待未来 Docker 能让用户清楚而直接地控制代理注入行为 —— 而不是陷入这种幽灵般的默认状态。

- - -


一次关于 Docker Desktop 与网络代理冲突的深度排查

---
title: 我思故我在屏前：一次对“理所当然”的技术探寻
publishDate: 2025-04-22T22:01:00.000Z
excerpt: 总有那么些瞬间，觉得我们对周遭的世界太过“理所当然”。
featuredImage: /uploads/下载.jpg
tags:
  - 与曦
  - 计算机
slug: '20250423060100'
---
总有那么些时刻，我意识到自己对周遭的世界——尤其是那些每日依赖的技术造物——是多么地习以为常，近乎一种无意识的接受。就像此刻，我指尖轻触键盘，屏幕亮起，网页在眼前展开，这一切流畅得仿佛是宇宙的固有法则。但今天，我选择不再“理所当然”。我试图潜入这日常运作的表象之下，去触碰那些支撑起我数字生活的底层逻辑，这不仅是对技术的探究，更像是一场关于认知、实在与“我”之存在的哲学追问。

我首先将目光投向了构成这台机器的物理实体——硬件、主板、CPU、内存、硬盘... 这些名词背后，是一个我每日互动却从未深思的微缩宇宙。冯·诺依曼先生定义的控制器、运算器、存储器、输入输出，构成了这个宇宙的秩序。我尝试想象开机那一瞬：电流涌入，硅晶片上亿万晶体管构成的精密结构被激活，自检程序启动，最终，操作系统这个“数字灵魂”被唤醒，点亮我所熟悉的界面。当我点击计算器图标，输入“1+1”，这简单的动作背后，是数据在我未见的内存、CPU缓存、寄存器间高速流转，是控制器无声地发出指令，运算器冰冷地执行逻辑，最终由GPU将结果“绘制”于我眼前的屏幕。这整个过程，对我而言，是“魔法”，是日常，但细思之下，却关乎信息如何在物理世界中被表征与处理的根本问题。

试图在脑海中串联起这完整的流程，追踪每一个微弱电信号的传递，想象每一个部件间的精密交互，老实说，这让我感到一种眩晕，一种因无限细节而生的“认知过载”。我不禁要问：那信号，究竟是什么？是电压的高低状态吗？它又是如何在微观尺度上，穿越亿万阻碍，精准无误地传递我的意图？一旦开始追问，便如同陷入了博尔赫斯式的迷宫，细节无穷无尽。这或许就是所谓的“分析瘫痪”吧？渴望找到所有拼图，砌成完美的认知之墙，却可能在寻找最后那块无关紧要的碎片时，迷失了整座大厦的宏伟。

这让我反思，理解世界或许本就需要接受不同抽象层级的存在。如同我们无法同时看清山的轮廓与每一片树叶的纹理。先把握整体的“山形”，再去探究局部的“肌理”，最终带着对细节的理解，重新审视整体，或许能获得更圆融的认知。这听起来充满智慧，但实践中，我需要不断与内心那股“刨根问底”、追求终极实在的冲动进行“对话”与“和解”。这是否也暗示着，我们对现实的理解，本身就是一种建构，一种在特定层级上的有效抽象？

下午，我的探索转向了将我与世界连接的网络。一个域名，比如我常用的某个网站，它是如何从一串字符，变成指引数据流向的冰冷IP地址，最终让我看到远方服务器上的内容？DNS查询，这个看似简单的动作，实则是一场涉及我本地设备缓存、本地DNS服务器（那个默默替我“跑腿”的解析器）、乃至全球分布的根服务器、顶级域服务器、权威服务器的复杂“接力”。递归与迭代，这些术语背后，是信息在我看不见的世界里，遵循着既定协议进行的分布式协作。这不到一秒的查询，数据包可能已经进行了一次“环球旅行”，而我对此浑然不觉。

接着是TCP的三次握手——那个被比作“喂，在吗？”“在！”“好的，开始说吧！”的确认过程，它在我与服务器间建立起一条虚拟的、可靠的通道，承载着信任与承诺。然后，我的HTTP请求发出，服务器响应，数据包（HTML、CSS、JS...）穿越物理的光纤或无形的电波，“流淌”回我的设备，浏览器这个“翻译官”再将它们渲染成我眼中的页面。如果加上HTTPS，那更是在数据传输前，进行了一场复杂的加密“握手”，以数学的严谨性确保我的信息不被窃听、不被篡改，仿佛在混乱的数字世界中构建起一个私密的对话空间。

将这一切简化，互联网的本质，似乎就是数据包遵循着一套层层嵌套的规则（应用层、传输层、网络层、链路层、物理层）进行封装、寻址、传输和解构的过程。我的每一个意图，都被转化为数据，精心“打包”，标记好地址，通过某种我无法直接感知的物理方式（光脉冲或电磁波），精准地送达目的地，再被还原。这让我思考，我们所谓的“交流”，在多大程度上依赖于这些被设计出来的、确保信息传递的底层协议与媒介？

从习以为常的现象出发，一路追溯，触碰到了支撑我数字体验的硬件与网络逻辑的冰山一角。我眼前的“魔法”至少不再那么神秘莫测。我开始理解，我与这个世界的互动，很大程度上是建立在这些人类智慧精心构建的复杂系统之上。

哪怕只是理解了冰山一角，那种“原来如此”的顿悟时刻，带来的满足感足以驱散“分析瘫痪”的阴霾。看似“理所当然”的日常背后，蕴藏着多么深邃的秩序与逻辑。或许，对这些“理所当然”保持好奇，去问问“为什么”，不仅能让我们更懂技术，也能让我们更深刻地理解自身的存在以及我们与世界的关系。
