Zed 编辑器网络设置：代理、远程开发与 AI 功能请求各走哪条路

Zed 的网络设置，先搞清楚「本地」和「远端」两头

Zed 是近几年增长很快的一款原生编辑器，很多开发者把它当作 VS Code 之外的轻量选择。与传统编辑器不同的是，Zed 把 AI 功能、协作和远程开发都内置在一起，这意味着一次操作可能同时涉及本地客户端、远端服务器和云端模型三头的网络。网络不稳时，判断问题出在哪一头，比任何调参都重要。本文对照 Zed 官方文档（查阅时间 2026 年 10 月），分成代理设置、远程开发、AI 功能三块说明，文档没有写清楚的地方会单独指出，并给出自己验证的方法。设置项名称可能随版本变化，请以你本机的版本为准。

第一块：proxy 设置写法与协议差异

settings.json 里的 proxy 怎么写

官方文档说明，在 settings.json 里用 proxy 键即可配置网络代理，支持 http、https、socks4、socks4a、socks5 和 socks5h。没有配置这一项时，Zed 会尝试读取 http_proxy、https_proxy、all_proxy 这些环境变量（大小写都可以），要排除某些主机或网段，用 NO_PROXY 环境变量，支持逗号分隔的主机名或 CIDR。

{
  "proxy": "socks5h://127.0.0.1:1080"
}

这里的地址和端口只是示例，换成你自己本地客户端监听的地址。这个设置适用于 Zed 自己发起的网络请求，官方说明其中包括语言服务器和扩展的下载。

socks5 和 socks5h 有什么区别

文档标注得很清晰：socks5 使用本地 DNS 解析，socks5h 则把域名交给代理端解析，socks4 和 socks4a 同理。差别在于域名解析发生在哪一边：如果域名在本地解析，得到的地址可能和代理端解析出的不同，尤其在解析结果会因地区而不同的服务上，很容易出现「终端能连、编辑器不能连」的现象。遇到某个域名连不上时，可以先把 socks5 改成 socks5h 对照。DNS 解析不一致的成因可以再看DNS 泄漏是什么。

第二块：远程开发，远端不会继承本地代理

Zed 的远程开发按官方说法把界面留在本地，把语言服务器、任务和终端放在远端，两者通过 SSH 通信。本地会调用 ssh 建立 ControlMaster 连接，再在上面复用开发协议、终端和任务的连接。连接设置里的 ssh_connections 可以写主机、用户名、端口、额外参数和昂称，并且会继承 ~/.ssh/config，所以已经配好的跳板、密钥不用重写。这部分的写法和复用原理，可以和VS Code Remote-SSH 跨境连接的两个故障点对照着看。

远程服务端二进制是谁下载的

默认情况下，Zed 会让远端机器直接从官方站点下载服务端二进制，存放在远端的 ~/.zed_server 目录。如果远端的外网访问受限，文档给出的办法是在连接设置里添加 "upload_binary_over_ssh": true，让本地先下载，再通过 SSH 上传到远端。这和 VS Code 里「服务端由本地下载后传输」的思路是一致的。

远端需要访问外网时代理怎么配

官方文档明确写到：远程服务器不会继承本地的代理设置，需要在远端的 ~/.bashrc 等位置设置环境变量，或在远端的 settings.json 里配置。也就是说，语言服务器在远端下载依赖、远端终端里的 git、npm 访问外网时，走的都是远端自己的网络环境，和你本地配的代理无关。这是「本地代理配了，远端依然超时」最常见的原因。

网络请求来源	走哪一端的网络	需要配置的位置
本地编辑器自身（扩展、语言服务器下载）	本地	本地 settings.json 的 proxy
远端服务端与语言服务器	远端	远端环境变量或远端 settings
远端终端里的命令行工具	远端	远端 shell 的代理变量
本地和远端之间的 SSH 连接	本地出口	~/.ssh/config，可用 ProxyJump

第三块：AI 功能的请求，文档没写的部分怎么自己验证

Zed 的 AI 设置在 Agent Settings 里，官方说明支持 Zed 托管模型、自带密钥、已有订阅、网关服务（如 OpenRouter、Bedrock 等）和本地模型（如 Ollama、兼容 OpenAI 接口的服务）几类，密钥存在系统密钥链里，而不是 settings.json。需要自定义接口地址时，可以通过 settings.json 里的 api_url 指向兼容的网关或自建服务。

AI 请求是从本地还是远端发出的

所查阅的 AI 配置文档没有明确说明模型请求是从客户端直接发出，还是经过 Zed 自己的服务，也没有说明代理如何处理，所以这一点不要靠猜。自己验证的方法很直接：触发一次 AI 对话，同时在本地用 lsof -i -n -P | grep -i zed（Linux 可用 ss -tnp）查看连接对端，在远端用 ss -tnp 看有无对应连接，就能确认请求实际从哪一端发出。确认之后再决定在哪一端配置代理，避免两端都配、反而互相干扰。

协作功能遇到延迟怎么判断

Zed 的协作面板支持频道和私人通话，可以实时共同编辑同一个项目，分享项目时协作者能访问你项目内的本地文件。所查阅的协作文档并没有列出具体的网络协议、带宽和延迟要求，因此遇到延迟时最实用的方法是先用 mtr 或 ping 测到对方和服务端的线路质量，再把语音与编辑同步的卡顿作为两个独立现象记录，比笼统地说「协作很卡」更容易定位。

1. 先在本地设置 proxy 或环境变量，确认扩展和语言服务器能正常下载。
2. 远程开发时在远端 shell 里单独测 curl 能否访问外网，再决定是否要开启 upload_binary_over_ssh。
3. 遇到 AI 功能超时，用上面的连接查看命令确认请求来自哪一端。
4. 通过 Zed 的 Open Log 命令查看连接日志，对照官方排障建议。

代理、环境变量的写法和 NO_PROXY 的误区，在 代理与超时环境变量的正确写法 里有更详细的说明。编辑器的补全卡顿如何分段定位，可以参考Cursor 补全卡顿的三段定位方法，思路同样适用于 Zed。

只想省事时：让本地和远端都走稳定出口

代理要分本地和远端两头配置，是很多人觉得麻烦的地方。如果你的本地开发机已经有一条稳定的出口，就可以把已配置好的线路用于编辑器自身、SSH 连接和 AI 请求；远端服务器则按官方说明单独配置。NasaCode 在客户端侧提供分流规则和 AI 智能路由，适合把 Zed 这类编辑器的外部请求和其他流量区别对待；是否满足你的场景，建议用上面的连接查看命令把实际走向确认一遍。

小结

Zed 的网络设置要分「本地、远端、AI」三头看：本地用 proxy 键和环境变量，远程服务端不继承本地代理，需要在远端单独配置或使用 upload_binary_over_ssh，AI 请求的走向官方文档没写，用连接查看命令自己确认。设置项已对照查阅时的官方文档，版本更新后请重新核对。