无尘阁日记

SSE 协议小白指南：服务器主动"喊"你一嗓子

Tue, 04 Aug 2026 18:53:46 +0800

如果你做过网页，一定熟悉这种模式：浏览器问服务器要数据，服务器给了，对话就结束了。那如果服务器想主动告诉你”有新消息了”，怎么办？

刷新页面？太蠢。轮询（每隔几秒问一次）？浪费流量。WebSocket？有点重。

这时候就该 SSE（Server-Sent Events，服务器发送事件） 出场了。它专门解决一个简单问题：让服务器能主动、持续地给浏览器推消息，而且实现起来比 WebSocket 简单十倍。

下面用 6 个核心要点 + 6 段可直接运行的代码，带你彻底搞懂 SSE。

1. 它是个”单行道”：只能从服务器流向浏览器

SSE 最大的特点就是单向。浏览器连上之后，服务器可以随时往浏览器发消息，但浏览器不能通过这条通道回传数据（要回传得另开一条 HTTP 请求）。

类比：SSE 像广播电台，服务器是电台，浏览器是收音机。电台可以一直播，收音机只能听，不能对着电台喊话。

例子：一个最简单的 SSE 服务端（Node.js）

const http = require('http');

http.createServer((req, res) => {
  // 1. 设置响应头，这是 SSE 的"身份证"
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive'
  });

  // 2. 每隔 2 秒推一条消息
  let count = 0;
  const timer = setInterval(() => {
    count++;
    res.write(`data: \u7b2c${count}\u6761\u6d88\u606f\uff0c\u65f6\u95f4\uff1a${new Date().toLocaleTimeString()}\n\n`);
    if (count >= 5) {
      clearInterval(timer);
      res.end();
    }
  }, 2000);

}).listen(3000, () => console.log('SSE \u670d\u52a1\u8dd1\u5728 http://localhost:3000'));

关键看第 9 行：Content-Type: text/event-stream，只要带上这个头，浏览器就知道”哦，这是 SSE，我要用 EventSource 来接收”。

2. 消息格式极其死板：必须以 `data:` 开头

SSE 的消息不是随便写的，它有一套固定格式。每条消息以 data: 打头，以两个换行符 \n\n 结尾。

data: \u8fd9\u662f\u4e00\u6761\u6d88\u606f\n\n

如果你要发多行，每行都要加 data:：

data: \u7b2c\u4e00\u884c\ndata: \u7b2c\u4e8c\u884c\n\n

浏览器收到后，会自动把多行拼接成一个字符串，中间用换行符连接。

例子：服务端发多行数据

res.writeHead(200, {
  'Content-Type': 'text/event-stream'
});

res.write(`data: {\n`);
res.write(`data:   "user": "\u6c5f\u6960",\n`);
res.write(`data:   "action": "login",\n`);
res.write(`data:   "time": "${new Date().toISOString()}"\n`);
res.write(`data: }\n\n`);

浏览器 EventSource 收到的事件中，event.data 会是：

{
  "user": "\u6c5f\u6960",
  "action": "login",
  "time": "2026-08-04T12:34:56.789Z"
}

3. 浏览器用 `EventSource` 接收，三行代码搞定

浏览器原生提供了 EventSource 对象，不需要任何库。

例子：前端接收 SSE

<!DOCTYPE html>
<html>
<body>
  <h1>SSE \u5b9e\u65f6\u6d88\u606f</h1>
  <ul id="list"></ul>

  <script>
    // \u53ea\u9700\u8981\u8fd9\u4e00\u884c\uff0c\u8fde\u63a5\u670d\u52a1\u7aef
    const es = new EventSource('http://localhost:3000');

    // \u6bcf\u6b21\u6536\u5230\u6d88\u606f\u5c31\u89e6\u53d1
    es.onmessage = (event) => {
      const li = document.createElement('li');
      li.textContent = event.data;
      document.getElementById('list').appendChild(li);
    };

    // \u51fa\u9519\u5904\u7406
    es.onerror = (err) => {
      console.log('\u8fde\u63a5\u65ad\u5f00\uff0c\u6b63\u5728\u91cd\u8fde...');
    };
  </script>
</body>
</html>

就这么简单。new EventSource(url) 创建连接，onmessage 收消息，onerror 处理断开。

4. 支持自定义事件名：不只是 `message`

默认情况下，所有消息都触发 onmessage。但你可以给消息分类，比如有的叫 price，有的叫 notice。

例子：服务端发送带事件名的消息

// \u63a8\u9001\u80a1\u7968\u4ef7\u683c
res.write(`event: price\n`);
res.write(`data: 38.50\n\n`);

// \u63a8\u9001\u7cfb\u7edf\u901a\u77e5
res.write(`event: notice\n`);
res.write(`data: \u60a8\u7684\u8ba2\u5355\u5df2\u53d1\u8d27\n\n`);

前端用 `addEventListener` 监听不同事件

const es = new EventSource('http://localhost:3000');

es.addEventListener('price', (e) => {
  document.getElementById('price').textContent = e.data;
});

es.addEventListener('notice', (e) => {
  alert('\u7cfb\u7edf\u901a\u77e5\uff1a' + e.data);
});

这样业务逻辑可以分门别类处理，代码更清爽。

5. 自带断线重连：浏览器比你更操心

SSE 有一个非常贴心的机制：如果连接断了，浏览器会自动帮你重连，默认间隔约 3 秒。你什么都不用写。

更妙的是，服务端可以控制重连间隔。比如你发一条 retry: 10000，浏览器就会在断开后等 10 秒再重连。

例子：服务端设置重连间隔 + 消息 ID

// \u544a\u8bc9\u6d4f\u89c8\u5668\uff1a\u65ad\u5f00\u540e 10 \u79d2\u518d\u8bd5
res.write(`retry: 10000\n`);

let id = 0;
setInterval(() => {
  id++;
  // \u6bcf\u6761\u6d88\u606f\u90fd\u5e26\u4e0a ID\uff0c\u65ad\u7ebf\u540e\u670d\u52a1\u7aef\u53ef\u4ee5\u4ece\u8fd9\u4e2a ID \u540e\u7eed\u4f20
  res.write(`id: ${id}\n`);
  res.write(`data: \u6d88\u606f\u7f16\u53f7${id}\n\n`);
}, 2000);

浏览器重连时，会在请求头里带上 Last-Event-ID: 5，服务端读到后就知道”哦，客户端已经收到第 5 条了，我从第 6 条开始发”，实现断点续传。

6. SSE vs WebSocket：别拿大炮打蚊子

很多人一听到”实时推送”就想到 WebSocket。但 SSE 在单工场景下更轻量。

特性	SSE	WebSocket
通信方向	服务器→客户端（单工）	全双工
协议	HTTP（兼容性好）	ws/wss（独立协议）
自动重连	705 原生支持	74c 需自己写
消息 ID/断点续传	705 原生支持	74c 需自己实现
二进制支持	74c 只能传文本	705 支持
实时游戏/双向高频通信	不合适	合适
股票推送/日志流/通知	完美	过重

例子：日志实时推送（SSE 比 WebSocket 更合适）

const fs = require('fs');
const http = require('http');

http.createServer((req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache'
  });

  // \u5b9e\u65f6\u8ffd\u8e2a app.log \u6587\u4ef6
  const stream = fs.createReadStream('/var/log/app.log', { start: fs.statSync('/var/log/app.log').size });
  stream.on('data', chunk => {
    const lines = chunk.toString().split('\n');
    lines.forEach(line => {
      if (line) res.write(`data: ${line}\n\n`);
    });
  });

}).listen(3000);

前端几行代码就能看实时日志，无需任何第三方库，也不需要处理 WebSocket 的握手和心跳。

一句话总结

SSE 就是基于 HTTP 的服务器单向推送协议。格式简单（data: + \n\n），浏览器原生支持（EventSource），自带重连和断点续传。如果你只需要服务器往浏览器发消息，完全没必要上 WebSocket，SSE 才是那把顺手的螺丝刀。

DeepSeek V4 Pro 到底强到什么程度？7月31日那次更新，把"参数神话"打穿了

Tue, 04 Aug 2026 15:57:59 +0800

2026 过半了。DeepSeek V4 Pro 正式版还没影，但整个圈子已经坐不住了。

为什么？因为 7 月 31 日，DeepSeek 在 API 文档的更新日志里，低调地挂出了一个叫 V4-Flash-0731 的东西。没有发布会，没有热搜通稿。但它干了一件让所有人愣住的事——一个总参数只有 Pro 六分之一的小模型，在智能体和代码基准上，把自家的 1.6 万亿参数旗舰预览版，反超了。

我先说结论，省得你往下划：V4-Pro 现在就是开源模型的天花板，逼近闭源旗舰；但真正炸裂的，是这次 Flash 的后训练飞跃，它把”堆参数等于变强”这条行业铁律，踩了一脚刹车。

V4-Pro 本身，已经够吓人

4 月 24 日 Preview 出来时，规格就摆在那：1.6 万亿总参数，每次只激活 490 亿；统一一百万 token 上下文。关键不在大，在省。新架构（CSA+HCA 混合稀疏注意力，加上 mHC 超连接和 Muon 优化器）把一百万 token 下的单 token 算力，压到 V3.2 的三成到一成，KV Cache 降到原来的十分之一不到。以前跑不动的超长任务，现在能跑了。

能力上，SWE-bench Verified 拿到 80.6（V4-Pro-Max 版），跟 Claude Opus 4.6/4.7 一个身位；Apex Shortlist 90.2，这个分数已经压过顶级闭源；Terminal Bench 2.0 也干过了 GLM-5.1 Thinking 和 Kimi K2.6 Thinking。Artificial Analysis 给它的智能指数 52 分，比 V3.2 的 42 涨了 10 分，是仅次于 Kimi K2.6 的第二大开源推理模型。

这些数字什么意思？意思是你花闭源三十分之一的钱，能拿到接近顶级闭源的交付质量。

7 月 31 日那一下，才是重点

V4-Flash-0731，参数一点没加（还是 2840 亿总参、激活 130 亿），纯粹靠后训练重练了一遍。结果 Terminal Bench 2.1 从预览版的 61.8 直接拉到 82.7，反超了 V4-Pro 预览版的 72.1。九项智能体加代码基准，它全赢了自家的 Pro 预览版；DeepSWE 一项，分差 41.6 分；最离谱的是 ALE 基准，跟全球顶级的 Claude Opus 4.8 只差半分。

换句话说：一个小了六倍的模型，把大哥按在地上摩擦。

这事为什么重要？因为过去两年行业默认”大力出奇迹”——参数越大越聪明。阿里 Qwen 3.8-Max 堆到 2.4 万亿，Kimi K3 堆到 2.8 万亿。结果 DeepSeek 用一版纯后训练，告诉市场：推理时的后训练和工程打磨，可能比堆参数更值钱。这跟 2025 年春天那次”DeepSeek 时刻”是一个逻辑——又一次正面刚了规模法则。

成本那块更狠

V4-Flash 定价 0.14 美元/百万输入、0.28 美元/百万输出，缓存命中能到 0.0028 美元，比 Anthropic 便宜 99% 以上。一个顶级 coding 能力，价格只要人家的 0.6%。7 月 31 日这版还首次原生支持 Responses API、适配了 Codex，老的 deepseek-chat 和 deepseek-reasoner 接口要在 10 月 24 日之前迁走。

普通人能得到什么

三点。第一，顶级代码能力便宜到可以忽略成本，中小团队和个人开发者直接能用。第二，一百万 token 上下文，等于能把一整个中等代码库塞进一次对话。第三，华为昇腾、寒武纪 Day 0 适配，国产算力跑得起万亿模型，这件事本身比模型分数更有分量。

时间点记一下：V4-Pro 正式版（GA）据报 8 月 10 到 20 日来，卡在内部 Harness 编程工具的封闭测试；V4-Flash 的 MIT 开源权重也在往 HuggingFace 上放。

我说点真心话

我自己有点矛盾。一方面，开源模型逼近闭源，价格塌到这个程度，对用 AI 干活的人是天大的好事。另一方面，知识截止还停在 2025 年、暂时没有视觉能力——它强，但还不是全能。别被”强到什么程度”的标题带节奏，它强在工程和性价比，不是样样第一。

我的建议就一句：现在就去 API 里把 V4-Flash-0731 接上试试，别等 Pro 正式版。便宜、快、够用，这才是大多数人的真实需求。

我是江楠。这期就聊到这，下期我拿它真跑几个 Agent 任务给你看。

让 AI 帮我发博客：一条只有踩过坑才写得出来的封装实录

Tue, 04 Aug 2026 15:09:57 +0800

<blockquote> 需求很简单：以后我可以在本机任意一个 agent 会话里说一句”把这个发到博客上”，文章就自动发到 jiangtian.top。但真做起来，从”能登上后台”到”稳定发一篇格式正确、分类正确的文章”，藏着的坑远比想象多。这是一篇不含滤镜的真实排障记录。 </blockquote> <h2 id="一先说结论">一、先说结论</h2> 我用 OpenClaw 做了一个叫 <code>blog-publish</code> 的 skill，放在本机 <code>~/.agents/skills/blog-publish/</code> 下。 以后无论哪个 agent 会话，只要用户说”发文章到博客”，它就会自动： 1. 登录后台（自动识别图形验证码，失败自动重试） 2. 自动把 Markdown 转成 HTML（因为 ZBlog 编辑器是”HTML / 可视化”双模切换，传裸 Markdown 会原样显示成 <code># 标题</code> 这种源码） 3. 拉取全量分类，让大模型判断内容归属，选正确分类 4. 返回文章链接 我发了好几篇草稿反复验证格式和分类，确认无误后才敢上线。这篇就是用它自己发出来的。 <h2 id="二技术栈侦察先搞清楚对手是谁">二、技术栈侦察：先搞清楚对手是谁</h2> 博客 <code>jiangtian.top</code> 用的是 Z-BlogPHP 1.7.3（nginx 服务器）。第一步不是写代码，而是摸清它的登录和发布机制。用 <code>curl</code> 一通探测： <ul> <li>后台登录页：<code>/zb_system/login.php</code>，正常</li> <li>发布入口：<code>/zb_system/cmd.php</code>，未登录时返回 500</li> <li><code>xmlrpc.php</code>：返回的竟然是首页 HTML —— 说明这个 ZBlog 没启用 XML-RPC 扩展，想走 WordPress 兼容 API 的路直接堵死</li> </ul> 所以只能走原生 cmd.php 接口，这就牵扯出好几个硬骨头。 <h2 id="三踩坑实录这才是干货">三、踩坑实录（这才是干货）</h2> <h3 id="坑-1登录-post-到哪密码还要-md5">坑 1：登录 POST 到哪？密码还要 MD5</h3> 一开始按直觉 POST 到 <code>login.php</code>，一直 500。抓了登录页的 JS 才看清： <div class="sourceCode" id="cb1"><pre class="sourceCode javascript"><code class="sourceCode javascript"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a>$("form").attr("action","cmd.php?act=verify"); <a href="#cb1-2" aria-hidden="true" tabindex="-1"></a>$("#password").val(MD5(strPassWord)); // 密码要 MD5 <a href="#cb1-3" aria-hidden="true" tabindex="-1"></a>$("#username").val(strUserName);</code></pre></div> 真相： - 登录不是提交给 <code>login.php</code>，而是 <code>cmd.php?act=verify</code> - 密码要先 MD5 加密，填到隐藏域 <code>password</code> - 用户名填到隐藏域 <code>username</code> <h3 id="坑-2csrftoken-有两个用错一个就非法访问">坑 2：csrfToken 有两个，用错一个就”非法访问”</h3> 这是最大的坑。登录页会给你一个 <code>csrfToken</code>（藏在隐藏 input 里）。但登录之后，你再想发布，用回这个 token 就报”非法访问”。 正确的 token 在后台首页里： <div class="sourceCode" id="cb2"><pre class="sourceCode html"><code class="sourceCode html"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a> <a href="#cb2-2" aria-hidden="true" tabindex="-1"></a><meta name="csrfToken" content="d73e305e9608258a48c9818d5b99b638"></code></pre></div> 注意它是 <code>content=</code> 而不是 <code>value=</code>，正则要先匹配对。我的做法：登录成功后，从后台首页 meta 标签重新取 token，用它来发布。这一步修完，发布立刻从”非法访问”变成”成功跳转”。 <h3 id="坑-3zblog-的-status-语义和你想的相反">坑 3：ZBlog 的 Status 语义和你想的相反</h3> 发布要传 <code>Status</code>。我的第一反应是 <code>1=发布, 0=草稿</code>。结果用 <code>status="draft"</code> 传 <code>Status:0</code> 发出去的竟是公开文章！ 去后台文章管理页看了一眼下拉框才明白： <div class="sourceCode" id="cb3"><pre class="sourceCode html"><code class="sourceCode html"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><option value="0">公开</option> <a href="#cb3-2" aria-hidden="true" tabindex="-1"></a><option value="1">草稿</option></code></pre></div> ZBlog 的 Status：0=公开（已发布），1=草稿，正好反了。这个不发现，以后每次”存草稿”都会误发成公开文章。 <h3 id="坑-4正文必须是-html不是-markdown">坑 4：正文必须是 HTML，不是 Markdown</h3> ZBlog 后台编辑器的正文是一个 “HTML / 可视化”双模切换的富文本区域——它存的是 HTML，可视化模式是拿这段 HTML 渲染出来的。 如果你把 Markdown 源码（<code># 标题</code>、<code>**加粗**</code>）直接塞进 Content 字段： - 可视化模式下会看到一堆 <code>#</code>、<code>**</code> 星号，格式全乱 - “HTML 模式”里倒是能看到源码，但那不是人看的 解决办法：发布前用 pandoc 把 Markdown 转成标准 HTML： <div class="sourceCode" id="cb4"><pre class="sourceCode bash"><code class="sourceCode bash"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a>pandoc -f markdown -t html --wrap=none input.md</code></pre></div> 得到 <code><h1></code>、<code></code>、<code><ul></code> 这种规范结构，ZBlog 就能正确渲染成带格式的文章。这一步我一开始也漏了，导致第一版发出去的文章在可视化模式下是乱的。 <h3 id="坑-5图形验证码纯-ocr-不够得多引擎投票-重试">坑 5：图形验证码，纯 OCR 不够，得”多引擎投票 + 重试”</h3> ZBlog 登录要图形验证码：5 位字符（大小写字母+数字混合），背景/字符颜色随机，还有斜向干扰线，JPEG 压缩还严重。 先测各种 OCR： - tesseract：对这张图”顾此失彼”，不同参数下时而准时而空 - macOS Vision：部分图完美，部分图空或串符号 结论：没有任何单一引擎能稳定全对。 最终方案是多引擎投票 + 自动重试循环： - 同时跑 tesseract（多个分段模式）和 Vision，收集候选 - 取出现次数最多的候选 - 验证码错了就换一张新的、重新识别、重新登录，直到成功 实测登录通常 1~3 次尝试搞定，最多 10 来次内必成。ZBlog 这里没有防爆破次数限制（连试 7 次错误都不锁），所以重试策略完全可行。 <h3 id="坑-6分类不能硬编码要拉全量让大模型选">坑 6：分类不能硬编码，要拉全量让大模型选</h3> 第一版我图省事，把”技术笔记”硬编码成 <code>category=3</code> 传进去。这有两个问题： 1. 分类 ID 是站点相关的，换个博客就全对不上 2. 内容归属应该由理解语义的模型来判断，而不是写死 正确做法：发布前先调用 <code>get_categories()</code> 把全量分类（我这边有 60 多个）拉下来，然后让大模型读文章内容、判断它最该进哪个分类，再传对应 ID。这样”这篇技术文章进技术笔记、那篇读书心得进读书笔记”，才是真智能。 <h2 id="四最终发布的协议存个档">四、最终发布的协议（存个档）</h2> 理顺之后，完整调用协议如下： <pre><code>【登录】 GET /zb_system/login.php # 取 csrfToken 和会话 cookie GET /zb_system/script/c_validcode.php?id=login&time=m # 下载验证码 POST /zb_system/cmd.php?act=verify 字段: csrfToken, username, password(MD5), verify, savedate 【发布】 1. get_categories() # 拉全量分类, 大模型选出正确分类 2. pandoc md->html # 正文转 HTML 3. GET /zb_system/admin/index.php # 重新取后台 csrfToken (meta标签) 4. POST /zb_system/cmd.php?act=ArticlePst 字段: ID=0(新建), Title, Content(HTML), Cate_ID, Tag, Status(0公开/1草稿), Alias, Intro, csrfToken 【删除】 GET /zb_system/cmd.php?act=ArticleDel&id=X&csrfToken=Y</code></pre> <h2 id="五几个值得记住的通用经验">五、几个值得记住的通用经验</h2> <ol type="1"> <li>动手前先”侦察”：用 curl 看响应头、抓 JS、看表单字段，搞清楚生态再写代码。你以为的”标准接口”往往是错的。</li> <li>500 不一定是服务器挂了：ZBlog 用”HTTP 500 + 错误页”来优雅表达”验证码错误”这类业务失败。别被状态码吓到，去看响应体。</li> <li>登录成功 ≠ 能发文章：cookie 有了、后台进了，但发布用错 csrfToken 照样”非法访问”。每种操作的鉴权上下文要分开测。</li> <li>富文本编辑器一律收 HTML：凡是”HTML/可视化”切换的编辑器，Content 字段只认 HTML，别图省事塞 Markdown。</li> <li>字段语义务必实测：Status 的 0/1 我完全想反了。一定要发一篇草稿实测，别轻信直觉。</li> <li>分类让模型选，别硬编码：拉全量分类 → 大模型判断归属 → 提交，可迁移、更智能。</li> <li>测试垃圾随手清理：我发的那几篇测试文章最后都删掉了（404 确认），没给博客留脏数据。</li> </ol> <h2 id="六成果">六、成果</h2> 以后我从任何 agent 会话里说一句”把这篇发到技术笔记”，文章就会自动以正确的 HTML 格式、正确的分类落到 jiangtian.top。这篇就是用它自己发出来的第一篇文章。 （注：中途所有带”测试”的草稿均已删除，无残留。） <hr /> 如果你也在折腾 ZBlog / 自建博客的自动化，希望这些坑能帮你少走弯路。

两台 mac 电脑直接互传文本

Thu, 04 Jun 2026 14:49:07 +0800

你这个界面不能直接粘贴文本发送。Finder 里的“隔空投送”主要是用来发现设备、拖文件发送的，不是聊天框。

方法一：把文本变成 txt 文件再发

最稳。

打开 文本编辑
粘贴你的文本
保存成一个文件，比如：

临时文本.txt

回到你这个“隔空投送”窗口
把这个 txt 文件拖到对方 Mac 头像上

或者右键文件：

共享 → 隔空投送 → 选择另一台 Mac

方法二：从某些 App 里直接共享文本

比如你在 Safari、备忘录、文本编辑里选中一段文字：

选中文字 → 右键 → 共享 → 隔空投送

但这个不一定每个 App 都支持，所以不如 txt 文件稳定。

方法三：装 LocalSend，专门传文本

如果你经常两台 Mac 互发文字，建议用 LocalSend。

它可以直接发：

文字
文件
文件夹
图片

不需要登录账号，不走云端，同一个 Wi-Fi 下就行。

你现在最快的做法

直接这样：

文本编辑 → 粘贴内容 → 保存成 txt → 拖到隔空投送里发

一句话：AirDrop 不是微信聊天框，想发文本片段，最好先保存成 txt 文件再投送。

Windows 安装 DeepSeek-TUI 踩坑：不是 PATH 问题，是它改名了

Thu, 04 Jun 2026 14:44:00 +0800

这次踩的坑，表面看是 Windows 找不到命令，实际根因是：DeepSeek-TUI 已经改名为 CodeWhale 了。

我一开始按老教程安装：

npm install -g deepseek-tui --registry=https://registry.npmmirror.com

终端提示安装成功：

changed 1 package

看起来没问题。

但执行：

deepseek

却提示：

deepseek 不是内部或外部命令，也不是可运行的程序

于是第一反应就是：环境变量没配好。

一、第一层误判：以为是 PATH 没加

Windows 下 npm 全局命令一般会安装到这个目录：

C:\Users\Administrator\AppData\Roaming\npm

所以我先把这个路径加进系统环境变量。

PowerShell 临时加 PATH 的写法是：

$env:Path += ";C:\Users\Administrator\AppData\Roaming\npm"

注意，这里不能写成：

set PATH=%PATH%;%APPDATA%\npm

这个是 CMD 写法，不是 PowerShell 写法。

如果你在 PowerShell 里执行 CMD 的写法，就会报类似这样的错误：

无法加载模块 %APPDATA%\npm

所以这里第一个坑是：

PowerShell 用 $env:变量名，CMD 才用 %变量名%。

二、第二层排查：PATH 加好了，还是找不到

后来我专门写了一个脚本，把 npm 全局路径永久加入系统 Path。

脚本执行后显示：

已成功加入系统环境变量 Path:
C:\Users\Administrator\AppData\Roaming\npm

说明环境变量已经加成功了。

但是继续检测：

Get-Command deepseek
Get-Command deepseek-tui
Get-Command codewhale

结果还是：

未找到命令：deepseek
未找到命令：deepseek-tui
未找到命令：codewhale

这时候就可以判断了：

这已经不是 PATH 的问题了。

如果 PATH 有问题，脚本不会显示加入成功。

如果 PATH 已经成功，但命令还是找不到，那就说明 npm 安装的包本身没有生成对应的命令入口。

也就是说：

npm install -g deepseek-tui

虽然执行成功，但它未必还会生成 deepseek 这个命令。

三、真正原因：DeepSeek-TUI 改名成 CodeWhale

真正原因是：DeepSeek-TUI 项目已经改名为 CodeWhale。

以前老教程里写的是：

npm install -g deepseek-tui
deepseek

现在应该改成：

npm install -g codewhale
codewhale

旧的 deepseek-tui 包已经不适合作为新安装方式了。

所以这次的坑，不是 Node 没装好，不是 npm 镜像问题，也不是 Windows 环境变量一定没配好，而是教程过期了。

一句话：

老名字叫 deepseek-tui，新名字叫 codewhale。以后别再用 deepseek 启动，直接用 codewhale。

四、正确解决方式

直接执行：

npm uninstall -g deepseek-tui
npm install -g codewhale --registry=https://registry.npmmirror.com

安装完成后检查：

Get-Command codewhale
Get-Command codewhale-tui

再查看版本：

codewhale --version

最后启动：

codewhale

如果你想看 npm 到底把命令装到哪里，可以执行：

npm config get prefix

正常情况下会返回类似：

C:\Users\Administrator\AppData\Roaming\npm

然后看这个目录里有没有生成命令：

dir "C:\Users\Administrator\AppData\Roaming\npm" | findstr /i "codewhale deepseek"

如果这里能看到 codewhale.cmd，说明命令入口已经生成。

五、Windows 桌面执行脚本的小坑

如果脚本放在桌面，推荐这样进入桌面目录：

cd ([Environment]::GetFolderPath("Desktop"))

这个比手写路径更稳。

因为有些电脑的桌面可能不是：

C:\Users\Administrator\Desktop

而是 OneDrive 或其他目录。

进入桌面后执行：

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\fix-npm-path.ps1

这里的：

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

只是让当前 PowerShell 窗口临时允许执行脚本，不是永久关闭安全策略。

六、最终判断逻辑

遇到这种“安装成功，但命令找不到”的问题，不要一上来就反复重装。

按这个顺序排查：

1. 先看命令是否存在

Get-Command deepseek
Get-Command deepseek-tui
Get-Command codewhale

2. 再看 npm 全局目录

npm config get prefix

3. 再看目录里有没有命令文件

dir "C:\Users\Administrator\AppData\Roaming\npm" | findstr /i "codewhale deepseek"

4. 如果 PATH 没问题，但命令不存在

那就不是环境变量问题，而是包没有生成这个命令。

这次就是这个情况。

七、最终命令合集

最推荐直接用这一套：

npm uninstall -g deepseek-tui
npm install -g codewhale --registry=https://registry.npmmirror.com
Get-Command codewhale
codewhale --version
codewhale

如果仍然找不到，再检查：

npm config get prefix
dir "C:\Users\Administrator\AppData\Roaming\npm" | findstr /i "codewhale deepseek"

八、这次踩坑的核心结论

这次问题不是：

npm 没安装成功

也不完全是：

Windows PATH 没配好

而是：

DeepSeek-TUI 改名为 CodeWhale，旧命令 deepseek 已经过时

所以以后安装不要再按老教程写：

npm install -g deepseek-tui
deepseek

而是直接写：

npm install -g codewhale
codewhale

技术工具更新太快，很多时候最坑人的不是报错本身，而是教程已经过期了。

这次就是典型案例：
命令没错，环境也快配好了，结果项目名字变了。

什么是FDE工程师？

Sun, 31 May 2026 19:50:42 +0800

FDE 工程师是什么？

FDE = Forward Deployed Engineer，直译是：前线部署工程师 / 客户现场工程师。

更通俗地说：

不是坐在办公室只写产品代码的工程师，而是冲到客户真实业务现场，把 AI / 软件系统真正落地跑起来的人。

OpenAI 对 FDE 的描述是：负责和战略客户一起完成复杂的端到端模型部署，覆盖需求发现、技术范围定义、系统设计、构建和生产上线。(OpenAI)

它和普通工程师的区别

普通软件工程师更像是：

我负责把产品功能写好。

FDE 更像是：

我负责让客户的问题真的被解决，必要时我自己写代码、接系统、改流程、做上线、培训团队。

所以 FDE 其实是一个混合岗位：

角色	FDE 身上对应的能力
软件工程师	写代码、做集成、搭系统
解决方案架构师	设计技术方案
顾问	理解客户业务和痛点
项目经理	推动上线交付
产品经理	把客户反馈带回产品团队

为什么 AI 时代突然火了？

因为大模型不是装上就能用。

企业真正落地 AI，会遇到很多现实问题：

比如数据在哪、权限怎么控、怎么接 ERP/CRM/OA、怎么保证安全、怎么评估效果、怎么让业务团队真的用起来。

这时候光卖 API 不够，光讲方案也不够，需要一个既懂技术、又懂业务、还敢下场交付的人。

这就是 FDE。

Reuters 报道也把 FDE 称为当前 AI 领域非常热门的岗位之一，原因是它能把 AI 模型嵌入真实企业系统，解决“从试点到生产”的落地难题。(Reuters)

一句话理解

FDE 工程师 = 企业 AI 落地的“特种兵”。

不是纯程序员。

不是纯售前。

不是纯顾问。

而是：

带着技术武器，进入客户战场，直接把业务问题打穿的人。

适合什么人？

适合这类人：

懂代码，但不想只关在 IDE 里。

能和老板、业务负责人、技术团队都聊得明白。

喜欢解决真实复杂问题。

能接受不确定性、出差、客户现场、快速交付。

对 AI 应用、企业数字化、业务流程优化有兴趣。

对你最有价值的理解

你以后做企业 AI 智能体、AI 操作系统、AI 落地方案，其实最需要培养的就是 FDE 思维：

不只是“我会调模型”，而是“我能把模型接进企业业务流程，并让它产生可衡量的业务结果”。

这也是未来 AI 课程、AI 咨询、AI 交付里非常值钱的一类能力。

macOS 上 v2rayN 的 TUN 模式没生效，怎么排查和修复？

Sat, 30 May 2026 21:08:32 +0800

很多人以为：

只要 v2rayN 节点能连上，TUN 模式就一定生效。

其实不是。

节点能用，只代表代理核心本身通了。

TUN 能用，代表系统流量真的被接管了。

这两个不是一回事。

这次遇到的问题就是典型案例：

手动走 SOCKS5 代理可以访问 Google。

但是浏览器、终端、系统直连还是访问不了。

这说明什么？

说明代理链路本身是好的，但系统流量没有真正走进 TUN。

一、先看现象

诊断结果里有三个关键现象。

第一个：

127.0.0.1:10808 正在监听

说明本机 SOCKS5 代理端口已经起来了。

第二个：

curl --socks5-hostname 127.0.0.1:10808 https://www.google.com

可以返回：

HTTP/2 200

说明节点、代理核心、远程链路都是正常的。

第三个：

curl -I https://www.google.com

直接访问超时。

同时：

127.0.0.1:10809 Connection refused

说明 HTTP 代理端口没有起来。

这几个现象合起来，结论就很清楚：

代理核心没坏。

节点没坏。

真正的问题是：

系统流量没有被 TUN 接管。

二、什么是 TUN 模式？

普通代理模式，一般是这样的：

软件自己设置代理。

浏览器自己设置代理。

终端自己设置代理。

哪个软件设置了，哪个软件才走代理。

而 TUN 模式不一样。

TUN 模式会在系统里创建一个虚拟网卡，然后把系统流量导进这个虚拟网卡，再交给代理核心处理。

简单说：

普通代理是“软件自己走代理”。

TUN 模式是“系统帮所有流量走代理”。

所以 TUN 模式生效后，理论上你不用单独给浏览器、终端、npm、OpenClaw 配代理，它们也应该能自动走代理。

但前提是：

TUN 真的启动成功了。

路由真的被改了。

DNS 真的被接管了。

三、TUN 没生效的典型表现

如果你遇到下面这些情况，基本就可以怀疑 TUN 没生效。

1. SOCKS5 手动访问成功

比如：

curl -I --socks5-hostname 127.0.0.1:10808 https://www.google.com

能成功。

这说明节点本身没问题。

2. 直接访问失败

比如：

curl -I https://www.google.com

失败、超时、无法连接。

这说明系统流量没被接管。

3. 浏览器不设置代理就访问不了

如果浏览器只有在手动设置 SOCKS5 代理后才能访问，关掉代理就不行，也说明 TUN 没真正接管系统流量。

4. 没有新的 utun 网卡

macOS 上 TUN 通常会创建 utun 相关虚拟网卡。

可以用这个命令看：

ifconfig | grep -Ei "utun|sing|tun" -A 8

如果开了 TUN 之后完全看不到相关变化，大概率 TUN 根本没起来。

四、这次问题的根因判断

这次日志里，最关键的是：

SOCKS5 10808 成功
HTTP 10809 refused
直连 Google timeout

这说明：

v2rayN / xray / sing-box 代理核心至少有一部分是正常的。

因为 SOCKS5 已经能访问外网。

但系统流量没有自动走代理。

也就是说：

TUN 模式没有真正生效。

进一步看，还有一个问题：

HTTP 代理端口 10809 没有监听。

所以如果某些软件配置的是：

http://127.0.0.1:10809

也会直接失败。

这类失败不是节点失败，而是本机端口没开。

五、第一步：确认核心类型，优先用 sing-box

macOS 上使用 TUN，建议优先使用 sing-box core。

因为 TUN、路由接管、DNS 劫持这些能力，sing-box 更适合。

在 v2rayN 里检查：

设置
核心类型
切换为 sing-box

切换之后，重新选择节点。

然后重新开启 TUN。

不要一边用 xray，一边指望 TUN 一定能稳定接管所有系统流量。

六、第二步：彻底重启 v2rayN 和代理核心

有时候 TUN 开关点了，但核心没有正确重载。

这时候不要只点界面按钮。

直接把相关进程杀掉：

pkill -f v2rayN
pkill -f sing-box
pkill -f xray

然后重新打开 v2rayN。

重新选择节点。

重新开启 TUN。

如果 macOS 弹出管理员密码授权，一定要允许。

因为 TUN 需要创建虚拟网卡、修改系统路由，这不是普通权限能完成的。

七、第三步：确认 TUN 网卡是否创建成功

开启 TUN 后，执行：

ifconfig | grep -Ei "utun|sing|tun" -A 8

如果看到新的 utun 相关接口，说明 TUN 至少创建了虚拟网卡。

如果完全没有变化，说明 TUN 没创建成功。

这时候重点查：

v2rayN 是否有管理员权限。

sing-box 是否正常启动。

TUN 配置是否开启。

macOS 是否阻止了相关网络权限。

八、第四步：确认系统路由是否被接管

TUN 模式不是创建虚拟网卡就结束了。

还要把流量导过去。

继续执行：

netstat -rn -f inet | head -n 40

如果 TUN 生效，路由表里通常会出现和 utun 有关的路由。

如果没有任何路由变化，说明：

TUN 网卡可能起来了，但系统流量没走进去。

这时候重点查 v2rayN 的 TUN 配置。

九、第五步：检查 TUN 的关键配置

在 v2rayN 的 TUN 设置里，重点看这些选项：

Enable TUN：开启
Stack：mixed / system / gvisor，优先 mixed
Auto Route：开启
Strict Route：开启
Sniff：开启
DNS Hijack：开启

其中最关键的是：

Auto Route
DNS Hijack

Auto Route 负责让系统流量走 TUN。

DNS Hijack 负责把 DNS 查询也接管过来。

如果只开了 TUN，但没开 Auto Route，可能出现：

TUN 网卡存在，但流量没进去。

如果 DNS 没接管，可能出现：

IP 流量走了代理，但域名解析还是污染或失败。

十、第六步：检查 10808 和 10809 端口

执行：

lsof -nP -iTCP:10808 -sTCP:LISTEN || true
lsof -nP -iTCP:10809 -sTCP:LISTEN || true

正常情况下：

10808：SOCKS5 代理
10809：HTTP 代理

但不同客户端配置不一样。

如果只看到 10808，没有 10809，说明 HTTP 代理没有开。

这时候如果某些软件使用的是：

http://127.0.0.1:10809

就会失败。

可以临时改成 SOCKS5：

socks5h://127.0.0.1:10808

十一、第七步：用三条命令判断问题在哪

1. 测试直连

curl -I --connect-timeout 8 https://www.google.com

如果失败，说明当前系统默认链路不通。

2. 测试 SOCKS5

curl -I --socks5-hostname 127.0.0.1:10808 --connect-timeout 8 https://www.google.com

如果成功，说明节点和 SOCKS5 代理正常。

3. 测试 HTTP 代理

curl -I -x http://127.0.0.1:10809 --connect-timeout 8 https://www.google.com

如果失败并提示：

Connection refused

说明 10809 端口没有监听。

这时候不要怀疑节点。

应该去检查 HTTP 入站配置。

十二、完整排查脚本

可以直接复制执行：

echo "=== core process ==="
ps aux | grep -Ei "v2ray|v2rayn|xray|sing-box" | grep -v grep

echo "=== ports ==="
lsof -nP -iTCP:10808 -sTCP:LISTEN || true
lsof -nP -iTCP:10809 -sTCP:LISTEN || true

echo "=== tun interfaces ==="
ifconfig | grep -Ei "utun|sing|tun" -A 8

echo "=== route ==="
netstat -rn -f inet | head -n 40

echo "=== direct test ==="
curl -I --connect-timeout 8 https://www.google.com

echo "=== socks test ==="
curl -I --socks5-hostname 127.0.0.1:10808 --connect-timeout 8 https://www.google.com

echo "=== http proxy test ==="
curl -I -x http://127.0.0.1:10809 --connect-timeout 8 https://www.google.com

判断方法：

SOCKS 成功，直连失败，没有 utun：
TUN 没创建成功。

SOCKS 成功，直连失败，有 utun：
TUN 创建了，但路由或 DNS 没接管。

SOCKS 成功，HTTP 代理失败：
10809 没开，软件不要配置 http://127.0.0.1:10809。

SOCKS 失败：
节点、订阅、核心、远程链路有问题。

直连成功：
系统网络本身可以访问，不一定说明 TUN 生效。

十三、临时解决方案：先用 SOCKS5 接管系统代理

如果 TUN 一时修不好，可以先用系统代理顶上。

先确认网络服务名：

networksetup -listallnetworkservices

一般是：

Wi-Fi

然后执行：

networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off
networksetup -setsocksfirewallproxy "Wi-Fi" 127.0.0.1 10808
networksetup -setsocksfirewallproxystate "Wi-Fi" on

然后测试：

curl -I https://www.google.com

如果能通，说明系统代理已经把流量导到 SOCKS5 了。

这不是 TUN，但可以先解决访问问题。

十四、恢复系统代理

如果后面不想走系统代理了，执行：

networksetup -setsocksfirewallproxystate "Wi-Fi" off
networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off

然后再测试网络。

十五、最终修复路线

这类问题不要乱猜。

按这个顺序来：

1. 确认 SOCKS5 10808 是否可用。
2. 如果 SOCKS5 可用，说明节点没坏。
3. 检查 TUN 是否创建 utun 网卡。
4. 检查路由是否走 utun。
5. 检查 Auto Route 是否开启。
6. 检查 DNS Hijack 是否开启。
7. 检查 10809 HTTP 代理是否真的监听。
8. TUN 修不好时，先用 SOCKS5 系统代理临时解决。

这次问题最核心的一句话是：

节点没坏，v2rayN 也不是完全不能用。

真正的问题是：

TUN 没有把系统流量接管过来。

所以，不要一上来就重装。

先看端口。

再看 utun。

再看路由。

再看 DNS。

这样排查，才不会越修越乱。

用 chatgpt 的 session 代充值

Sat, 30 May 2026 19:38:45 +0800

问：

plus 充值，请先浏览器登录 https://chatgpt.com，之后打开 https://chatgpt.com/api/auth/session，点进去，把里面的内容全选复制给我即可这个的充值原理是啥？

答：

这种充值方式的原理，简单来说就是提取你账号的临时「通行证」（Access Token），让代充商家可以在不获取你账号密码的情况下，直接以你的身份进入系统完成支付。

核心原理拆解

获取会话凭证：你打开的那个链接，返回的是你当前登录状态的底层数据。在这堆数据中，最关键的一项叫做「accessToken」。这相当于你账号当前的一把临时钥匙。
规避风控拦截：ChatGPT 对支付环境的风控极其严格。如果商家直接用你的账号密码在他们的电脑（异地 IP）上登录，极大概率会触发 OpenAI 的安全警报，导致无法调出支付页面甚至直接封号。
伪造本人操作：商家拿到你复制的「accessToken」后，可以通过修改浏览器请求头等技术手段，把这把钥匙挂在他们自己的网络请求上。服务器一看到这把合法的钥匙，就会误以为是你在自己的设备上进行操作。
完成绑卡扣款：绕过风控后，商家就能顺利进入账单系统，绑定他们自己的虚拟信用卡完成扣款，从而让你的账号升级为 Plus。

潜在的安全与隐私风险

隐私完全暴露：这把临时钥匙的权限非常高。在它失效之前，商家不仅能帮你充值，理论上也可以读取、浏览甚至导出你的所有历史对话记录。
信用卡连带封号：第三方代充通常使用的是批量生成的虚拟信用卡。如果这张卡存在风险（比如拒付、灰产来源），OpenAI 的支付网关在后续清算时一旦发现异常，会直接封禁使用了该卡的账号。

如果你已经通过这种方式完成了充值，建议立刻前往 ChatGPT 的设置（Settings）中，找到安全相关选项并点击「Log out of all devices」（登出所有设备）。这个操作可以强制让你之前提取的「accessToken」立即失效，从而阻断商家继续访问你账号的可能。

Mac M1 上 v2rayN 提示“中国大陆证书问题访问不了”：一次真实排障复盘

Sat, 30 May 2026 19:27:23 +0800

一、问题背景

在 Mac M1 / Apple Silicon 设备上安装 v2rayN 后，用户反馈访问部分网站失败，v2rayN 提示类似：

中国大陆有证书问题，访问不了。

很多人第一反应会认为是“证书坏了”“系统证书不对”“网站证书异常”。但从实际排查过程看，这类问题不一定真是证书问题。

这次案例的真实原因是：

v2rayN 主程序启动了
xray / sing-box 核心也启动了
但 macOS 系统代理没有启用
而且实际代理端口不是默认的 10809 / 10808
同时 DNS 解析也存在异常

所以最终表现出来像是 TLS / SSL / 证书问题，但底层真正的问题是：

系统流量没有进入 v2rayN 代理，而是在直连；直连时 DNS 又解析异常，导致 TLS 握手超时。

二、先看现象：为什么看起来像“证书问题”？

执行检测脚本时，直连访问 https://www.google.com 出现了：

SSL connection timeout
curl: (28) SSL connection timeout

这句话非常关键。

它不是：

SSL certificate problem
certificate verify failed
unable to get local issuer certificate

如果是上面这类报错，才更像是系统证书链、根证书、目标证书或者中间人证书问题。

但本次是：

SSL connection timeout

这说明连接已经到了 TLS 握手阶段，但握手一直没有完成，最后超时。

通俗说就是：

不是证书校验失败，而是连到一个不正常的目标之后，TLS 握手卡住了。

三、第一处异常：DNS 解析不正常

检测结果里，www.google.com 被解析成了：

157.240.7.20

这个结果明显不正常。

157.240.x.x 更像 Meta / Facebook 相关 IP 段，不应该是 Google 常规解析结果。

同时 curl 里还出现了：

IPv6: 2001::1
IPv4: 157.240.7.20

这说明当前网络环境下 DNS 解析有较大概率存在以下情况之一：

1. DNS 污染
2. 路由器 / 热点 DNS 异常
3. 上游 DNS 不可靠
4. 网络链路对特定域名做了错误解析

DNS 解析错了之后，浏览器或者 curl 就会连到错误的 IP。连到错误 IP 后，TLS 握手自然容易失败、卡住、超时。

所以这里的第一条判断是：

直连链路不可靠，DNS 已经异常。

四、第二处异常：v2rayN 默认代理端口没有监听

检测脚本默认测试了两个常见端口：

HTTP 代理端口：10809
SOCKS5 代理端口：10808

但是检测结果显示：

127.0.0.1:10809 没有监听
127.0.0.1:10808 没有监听

随后通过 curl 测试代理访问：

curl -Iv -x http://127.0.0.1:10809 https://www.google.com

Connection refused
Failed to connect to 127.0.0.1 port 10809

再测 SOCKS5：

curl -Iv --socks5-hostname 127.0.0.1:10808 https://www.google.com

同样返回：

Connection refused
Failed to connect to 127.0.0.1 port 10808

Connection refused 的含义非常直接：

这个端口上没有程序在接收连接。

也就是说，不是节点不通，也不是远端服务器拒绝，而是本机 127.0.0.1:10809 / 127.0.0.1:10808 这两个代理端口根本没开。

五、第三处异常：v2rayN 核心其实启动了，但监听的是另一个端口

继续检查进程：

ps aux | grep -Ei "v2ray|v2rayn|xray|sing-box|mihomo|clash" | grep -v grep

可以看到：

v2rayN 主程序已启动
sing-box 已启动
xray 已启动

这说明 v2rayN 不是完全没运行。

再看监听端口：

lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "108|789|2017|2080|9090|v2ray|xray|sing|clash|mihomo"

发现实际监听的是：

xray TCP 127.0.0.1:59022 (LISTEN)

这一步直接把问题定位清楚了：

你以为代理端口是 10809 / 10808
但真实监听端口是 59022

所以之前拿 10809 / 10808 测代理，当然会失败。

六、第四处异常：macOS 系统代理没有启用

继续检查 macOS 系统代理：

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getsocksfirewallproxy Wi-Fi

结果显示：

Enabled: No
Server: 127.0.0.1
Port: 15236

Enabled: No
Server: 127.0.0.1
Port: 15236

Enabled: No
Server: 127.0.0.1
Port: 15235

这里有两个关键信息。

第一，Enabled: No：

系统代理没有启用

第二，系统记录的旧端口是：

15235 / 15236

但实际 xray 监听的是：

这说明系统代理配置和 v2rayN 当前实际监听端口完全错位。

最终状态就是：

v2rayN 核心在跑
但 macOS 系统流量没有走它
浏览器 / curl / 系统请求仍然在直连
直连 DNS 又异常
于是表现为 SSL / TLS / 证书类错误

一句话概括：

代理核心在旁边跑着，但系统流量没有进代理通道。

七、正确排查命令清单

1. 查看 v2rayN / xray / sing-box 是否运行

ps aux | grep -Ei "v2ray|v2rayn|xray|sing-box|mihomo|clash" | grep -v grep

如果没有任何输出，说明 v2rayN 或核心没起来。

如果能看到：

v2rayN
xray
sing-box

说明主程序和核心至少已经启动。

2. 查看本机实际监听端口

lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "108|789|2017|2080|9090|v2ray|xray|sing|clash|mihomo"

重点看类似：

127.0.0.1:59022 (LISTEN)

这个端口才是当前真实代理端口。

不要死盯 10809 / 10808，因为 v2rayN 可能会动态生成或使用其他端口。

3. 测试这个端口是 HTTP 代理还是 SOCKS5 代理

假设实际监听端口是 59022，先测 HTTP：

curl -Iv -x http://127.0.0.1:59022 --connect-timeout 10 --max-time 20 https://www.google.com -o /dev/null

再测 SOCKS5：

curl -Iv --socks5-hostname 127.0.0.1:59022 --connect-timeout 10 --max-time 20 https://www.google.com -o /dev/null

判断规则：

HTTP 那条成功：59022 是 HTTP 代理端口
SOCKS5 那条成功：59022 是 SOCKS5 代理端口
两条都失败：核心配置、节点、端口类型或入站配置可能有问题

4. 查看 macOS 系统代理状态

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getsocksfirewallproxy Wi-Fi

如果你不是用 Wi-Fi，可以先查看网络服务名称：

networksetup -listallnetworkservices

常见结果：

USB 10/100/1000 LAN
Wi-Fi
iPhone USB
Thunderbolt Bridge

如果当前网络是 Wi-Fi，就继续用 Wi-Fi。

八、修复方法一：在 v2rayN 里开启系统代理

最推荐先用图形界面操作。

打开 v2rayN，找到类似选项：

设置系统代理
自动配置系统代理
开启系统代理
Set system proxy
System Proxy

开启后，再执行：

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getsocksfirewallproxy Wi-Fi

看到：

Enabled: Yes

才说明系统代理真的打开了。

如果仍然是：

Enabled: No

那说明 v2rayN 没有成功写入 macOS 系统代理配置。

九、修复方法二：手动设置 macOS 系统代理

如果确认 59022 是 SOCKS5 代理端口，可以执行：

sudo networksetup -setsocksfirewallproxy Wi-Fi 127.0.0.1 59022
sudo networksetup -setsocksfirewallproxystate Wi-Fi on

验证：

networksetup -getsocksfirewallproxy Wi-Fi

正常应该显示：

Enabled: Yes
Server: 127.0.0.1
Port: 59022

如果确认 59022 是 HTTP 代理端口，可以执行：

sudo networksetup -setwebproxy Wi-Fi 127.0.0.1 59022
sudo networksetup -setsecurewebproxy Wi-Fi 127.0.0.1 59022

sudo networksetup -setwebproxystate Wi-Fi on
sudo networksetup -setsecurewebproxystate Wi-Fi on

验证：

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi

正常应该显示：

Enabled: Yes
Server: 127.0.0.1
Port: 59022

十、修复方法三：处理 DNS 异常

本次日志里 DNS 也明显不正常，所以建议把 DNS 改成更稳定的公共 DNS。

执行：

sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 8.8.8.8

然后清理 DNS 缓存：

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

重新测试：

dig www.google.com

如果 DNS 结果仍然异常，说明当前网络链路本身可能存在 DNS 污染或拦截。这时候更要先保证系统代理真正生效。

十一、如何判断已经修好？

1. 系统代理启用

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getsocksfirewallproxy Wi-Fi

至少对应协议要看到：

Enabled: Yes
Server: 127.0.0.1
Port: 正确端口

2. 代理端口有监听

lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "v2ray|xray|sing|59022|108|789"

要看到类似：

127.0.0.1:59022 (LISTEN)

3. 通过代理访问成功

HTTP 代理测试：

curl -Iv -x http://127.0.0.1:59022 https://www.google.com -o /dev/null

或者 SOCKS5 测试：

curl -Iv --socks5-hostname 127.0.0.1:59022 https://www.google.com -o /dev/null

如果看到：

HTTP/2 200
HTTP/1.1 200

或者没有 TLS 超时报错，说明代理链路基本正常。

十二、这类问题的排查模型

以后遇到 v2rayN、Clash、sing-box、xray 类似问题，不要一上来就重装。

按这个顺序排：

第一步：程序是否启动
第二步：核心是否启动
第三步：本地端口是否监听
第四步：系统代理是否开启
第五步：系统代理端口是否和实际监听端口一致
第六步：DNS 是否异常
第七步：通过代理 curl 是否成功
第八步：再考虑证书问题

很多所谓“证书问题”，本质并不是证书坏了，而是：

DNS 解析错了
系统代理没开
端口配错了
代理核心没监听
系统流量没走代理

十三、本次案例最终结论

本次问题不是典型证书问题。

真实原因是：

1. v2rayN 主程序已启动；
2. xray / sing-box 核心也已启动；
3. 但默认检测端口 10809 / 10808 没有监听；
4. 实际监听端口是 127.0.0.1:59022；
5. macOS 系统代理处于 Disabled；
6. 系统代理记录的端口还是旧的 15235 / 15236；
7. 当前 DNS 解析也异常；
8. 所以浏览器和 curl 仍然直连，导致 TLS 握手超时；
9. 最终表现成类似“证书问题”。

一句话总结：

v2rayN 不是没运行，而是系统流量没有接入它；修复重点不是重装证书，而是确认本地监听端口、开启系统代理，并修正 DNS。

OpenClaw 报错：Managed Codex app-server binary was not found 的根因与修复方法

Thu, 28 May 2026 20:56:57 +0800

OpenClaw 报错：Managed Codex app-server binary was not found 的根因与修复方法

一、问题现象

在 OpenClaw 使用 Codex 嵌入式代理时，出现如下报错：

Embedded agent failed before reply:
Managed Codex app-server binary was not found for @openai/codex.
Reinstall or update OpenClaw, or run pnpm install in a source checkout.
Set plugins.entries.codex.config.appServer.command or OPENCLAW_CODEX_APP_SERVER_BIN to use a custom Codex binary.

这个错误的直观表现是：

OpenClaw 已经收到了任务，也已经尝试启动 Codex 嵌入式代理，但在真正回复之前，Codex app-server 启动失败了。

换句话说，这不是模型回答质量问题，也不是 prompt 问题，而是 OpenClaw 在调用 Codex 本地服务时，找不到应该启动的 Codex app-server 可执行文件。

二、第一层理解：这个错误到底是什么意思？

这句话的核心是：

Managed Codex app-server binary was not found

意思是：

OpenClaw 的 Codex 插件默认会尝试使用它自己管理的 Codex app-server binary，也就是所谓的 managed binary。

但当前环境里，这个 managed binary 没找到。

所以 OpenClaw 给了三个方向：

Reinstall or update OpenClaw

重新安装或更新 OpenClaw。

run pnpm install in a source checkout

如果你是源码安装 OpenClaw，那么进入源码目录执行 pnpm install。

Set plugins.entries.codex.config.appServer.command or OPENCLAW_CODEX_APP_SERVER_BIN

手动指定 Codex app-server 的启动文件。

前两个办法适合普通安装缺失、源码依赖缺失的问题；但如果你反复重装仍然不行，就说明真正的问题不在 OpenClaw 主程序本身，而在 OpenClaw 找 Codex app-server 的路径逻辑上。

三、为什么重装 OpenClaw 也没用？

这类问题最容易误判成“OpenClaw 没装好”。

但实际排查下来，重装很多次仍然报错，通常说明：

OpenClaw 主程序是好的，Codex 也可能已经安装成功了。

真正坏的是：

OpenClaw 没有找到正确的 Codex app-server binary。

尤其在 Windows 环境里，经常会出现这种情况：

你已经通过 npm 安装了 @openai/codex，系统里也有 codex.cmd，但是 OpenClaw 的 Codex 插件默认并不会直接使用你 PATH 里的 codex.cmd。

它可能仍然去找自己插件目录里的 managed binary。

一旦这个 managed binary 没生成、没下载、没缓存成功、路径解析失败，或者 OpenClaw 当前版本在 Windows 上没有正确找到它，就会一直报：

Managed Codex app-server binary was not found

所以继续重装 OpenClaw 很可能只是重复覆盖主程序，而没有解决 Codex app-server binary 的真实路径问题。

四、错误排查过程

1. 第一反应：更新 OpenClaw

最先尝试的是：

openclaw update
openclaw doctor --non-interactive --fix
openclaw gateway restart

这个方向是合理的，因为如果只是 OpenClaw 安装不完整，更新和 doctor 修复可能解决。

但如果重装、更新、doctor 都无效，就要换思路。

2. 第二步：检查旧配置是否覆盖

然后排查 openclaw.json 里是否有旧的 Codex 配置，尤其是：

"appServer": {
  "command": "..."
}

如果这里写错路径，OpenClaw 会按错误路径启动 Codex。

所以之前尝试过删除：

plugins.entries.codex.config.appServer

并清理环境变量：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", $null, "User")
[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_ARGS", $null, "User")
[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_MODE", $null, "User")

这个方向也没错，因为旧配置确实可能覆盖默认行为。

但你的场景里，这一步仍然没有解决。

这就说明问题不是“旧配置乱指”，而是 OpenClaw 默认 managed binary 本身找不到。

3. 第三步：确认 Codex CLI 是否独立可用

最终切入点是：

不要再让 OpenClaw 自己猜 Codex 在哪里，而是先确认系统里的 Codex CLI 是否能独立运行。

执行：

codex.cmd app-server --help

如果这条命令可以正常输出帮助信息，说明 @openai/codex 本身没坏。

也就是说：

Codex 能跑，OpenClaw 找不到它。

这个判断非常关键。

它把问题从“Codex 没装好”改成了“OpenClaw 没有找到正确的 Codex 启动文件”。

4. 第四步：找到 codex.cmd 的真实路径

执行：

(Get-Command codex.cmd).Source

一般会输出类似：

C:\Users\你的用户名\AppData\Roaming\npm\codex.cmd

这个路径才是 Windows 下 npm 全局安装生成的 Codex 命令入口。

只要 codex.cmd app-server --help 能跑，这个路径就可以作为 OpenClaw 的 Codex app-server 启动入口。

五、最终解决办法：显式指定 OPENCLAW_CODEX_APP_SERVER_BIN

最终解决命令是：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

这条命令的意思是：

把系统里的 codex.cmd 路径写入用户级环境变量：

OPENCLAW_CODEX_APP_SERVER_BIN

OpenClaw 启动 Codex app-server 时，不再只依赖 managed binary，而是直接使用这个明确指定的 Codex 可执行文件。

然后确认一下：

[Environment]::GetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", "User")

如果能看到类似：

C:\Users\你的用户名\AppData\Roaming\npm\codex.cmd

说明环境变量写入成功。

接着关闭当前 PowerShell，重新打开一个新的 PowerShell。

注意：这一步非常重要。
环境变量写入之后，旧 PowerShell 窗口不一定立刻生效。

然后重启 OpenClaw gateway：

openclaw gateway stop

openclaw gateway start

或者：

openclaw gateway restart

最后检查状态：

openclaw gateway status

六、完整修复命令汇总

1. 安装或重装 Codex CLI

npm install -g @openai/codex

2. 测试 Codex app-server 是否能独立运行

codex.cmd app-server --help

如果能输出帮助信息，说明 Codex 本身可用。

3. 查看 codex.cmd 路径

(Get-Command codex.cmd).Source

4. 写入 OpenClaw Codex app-server 路径

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

5. 检查环境变量是否写入成功

[Environment]::GetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", "User")

6. 关闭 PowerShell，重新打开

这一步不要省略。

7. 重启 OpenClaw gateway

openclaw gateway stop

openclaw gateway start

或者：

openclaw gateway restart

8. 查看状态

openclaw gateway status

七、为什么这个办法有效？

因为这个错误的本质不是 OpenClaw 没装好，而是：

OpenClaw 的 Codex 插件默认要找 managed Codex app-server binary，但它没有找到。

而我们通过：

OPENCLAW_CODEX_APP_SERVER_BIN

直接告诉 OpenClaw：

不要猜了，就用这个 codex.cmd 来启动 app-server。

这相当于绕过了 OpenClaw 默认的 managed binary 查找逻辑，直接指定了一个已经验证可用的 Codex 启动入口。

这也是为什么前面重装 OpenClaw、清理配置、删除 appServer 配置都不一定有效，而最后这一步能解决。

八、这类问题的标准判断流程

以后再遇到类似报错，可以按这个顺序判断：

第一层：看错误关键词

如果看到：

Managed Codex app-server binary was not found

先判断为：

OpenClaw 找不到 Codex app-server binary。

不要先怀疑 prompt，也不要先怀疑模型。

第二层：确认 Codex 是否独立可用

执行：

codex.cmd app-server --help

如果这条命令失败，说明 Codex CLI 本身没装好。

如果这条命令成功，说明 Codex 没坏，是 OpenClaw 找不到它。

第三层：显式指定 Codex 路径

执行：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

然后重启 PowerShell 和 gateway。

第四层：检查 OpenClaw 配置

如果仍然失败，再检查：

openclaw.json

重点看有没有：

"appServer": {
  "command": "..."
}

如果有错误路径，删除或者修正。

九、经验总结

这次问题最大的坑在于：

错误提示里第一句就说：

Reinstall or update OpenClaw

所以人很容易陷入“反复重装”的循环。

但实际上，重装只能解决 OpenClaw 主程序或托管 binary 安装不完整的问题。

如果问题是 Windows 下 Codex binary 路径解析失败，或者 OpenClaw 没有使用 npm 全局安装的 codex.cmd，那么重装多少遍都可能没用。

真正有效的判断是：

codex.cmd app-server --help

只要这条命令能跑，就说明 Codex 在系统里是好的。

接下来要做的不是重装，而是把它的路径明确告诉 OpenClaw：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

最终一句话：

这个问题不是 Codex 不存在，而是 OpenClaw 没找到正确的 Codex app-server 启动入口。

解决方法也很简单：

先确认 codex.cmd 能跑，再用 OPENCLAW_CODEX_APP_SERVER_BIN 显式指定它。

无尘阁日记

SSE 协议小白指南：服务器主动"喊"你一嗓子

1. 它是个”单行道”：只能从服务器流向浏览器

例子：一个最简单的 SSE 服务端（Node.js）

2. 消息格式极其死板：必须以 data: 开头

例子：服务端发多行数据

3. 浏览器用 EventSource 接收，三行代码搞定

例子：前端接收 SSE

4. 支持自定义事件名：不只是 message

例子：服务端发送带事件名的消息

前端用 addEventListener 监听不同事件

5. 自带断线重连：浏览器比你更操心

例子：服务端设置重连间隔 + 消息 ID

6. SSE vs WebSocket：别拿大炮打蚊子

例子：日志实时推送（SSE 比 WebSocket 更合适）

一句话总结

DeepSeek V4 Pro 到底强到什么程度？7月31日那次更新，把"参数神话"打穿了

V4-Pro 本身，已经够吓人

7 月 31 日那一下，才是重点

成本那块更狠

普通人能得到什么

我说点真心话

让 AI 帮我发博客：一条只有踩过坑才写得出来的封装实录

两台 mac 电脑直接互传文本

方法一：把文本变成 txt 文件再发

方法二：从某些 App 里直接共享文本

方法三：装 LocalSend，专门传文本

你现在最快的做法

Windows 安装 DeepSeek-TUI 踩坑：不是 PATH 问题，是它改名了

一、第一层误判：以为是 PATH 没加

二、第二层排查：PATH 加好了，还是找不到

三、真正原因：DeepSeek-TUI 改名成 CodeWhale

四、正确解决方式

五、Windows 桌面执行脚本的小坑

六、最终判断逻辑

1. 先看命令是否存在

2. 再看 npm 全局目录

3. 再看目录里有没有命令文件

4. 如果 PATH 没问题，但命令不存在

七、最终命令合集

八、这次踩坑的核心结论

什么是FDE工程师？

FDE 工程师是什么？

它和普通工程师的区别

为什么 AI 时代突然火了？

一句话理解

适合什么人？

对你最有价值的理解

macOS 上 v2rayN 的 TUN 模式没生效，怎么排查和修复？

一、先看现象

二、什么是 TUN 模式？

三、TUN 没生效的典型表现

1. SOCKS5 手动访问成功

2. 直接访问失败

3. 浏览器不设置代理就访问不了

4. 没有新的 utun 网卡

四、这次问题的根因判断

五、第一步：确认核心类型，优先用 sing-box

六、第二步：彻底重启 v2rayN 和代理核心

七、第三步：确认 TUN 网卡是否创建成功

八、第四步：确认系统路由是否被接管

九、第五步：检查 TUN 的关键配置

十、第六步：检查 10808 和 10809 端口

十一、第七步：用三条命令判断问题在哪

1. 测试直连

2. 测试 SOCKS5

3. 测试 HTTP 代理

十二、完整排查脚本

十三、临时解决方案：先用 SOCKS5 接管系统代理

十四、恢复系统代理

十五、最终修复路线

用 chatgpt 的 session 代充值

核心原理拆解

潜在的安全与隐私风险

Mac M1 上 v2rayN 提示“中国大陆证书问题访问不了”：一次真实排障复盘

一、问题背景

二、先看现象：为什么看起来像“证书问题”？

三、第一处异常：DNS 解析不正常

四、第二处异常：v2rayN 默认代理端口没有监听

五、第三处异常：v2rayN 核心其实启动了，但监听的是另一个端口

2. 消息格式极其死板：必须以 `data:` 开头

3. 浏览器用 `EventSource` 接收，三行代码搞定

4. 支持自定义事件名：不只是 `message`

前端用 `addEventListener` 监听不同事件