OpenClaw 接 ChatGPT 或其他模型时报错 LLM request timeout
在 Windows 使用 WSL + Ubuntu 时，我碰到过一个最头疼的问题，现在终于解决了： 1LLM request timed out 我当时挂了 V2RayN，并开启了 TUN 和 PAC。最开始我一直以为是代理软件本身的问题。确实，关掉 TUN 后有一阵子可以连上；但随后又出现 ChatGPT 无法访问的问题。 后来我重新梳理目标：我需要的是“在正常访问 ChatGPT 的同时，让 OpenClaw 正常工作”，所以放弃了仅靠关 TUN 的临时方案。 经过排查，最终确认关键原因是 WSL 网络模式设置： 1networkingMode=mirrored 将其修改为： 1networkingMode=nat 问题立刻解决。本文记录完整排查过程和最终方案。 一、问题现象在 OpenClaw UI 中发送消息后超时，于是先在 WSL 中直接测试 OpenAI API： 1curl https://api.openai.com/v1/models 结果：一直卡住，没有任何返回。 二、确认 Windows 网络正常为了排除主机网络问题，在 Windows Powe...
无标题
![[Pasted image 20260304081842.png]]我目前有两个知识库 但是我发现 每个知识库都有一个.obsidian/plugins文件夹，这样导致每个知识库的插件是不能同步的后面我发现一个windows上的方式 叫符号链接（Symbolic Link）G:\Hexo_Blog_Raymond\source_posts.obsidian\plugins 这是我副的知识库的插件路径F:\Raymond_Obsidian.obsidian\plugins 这是我主知识库的插件路径我希望两个文件夹能够同步具体步骤：先删除副知识库的plugins文件夹，只保留主知识库的plugins文件夹然后执行创建符号链接命令（以管理员权限打开CMD）mklink /D “G:\Hexo_Blog_Raymond\source_posts.obsidian\plugins” “F:\Raymond_Obsidian.obsidian\plugins”
Obsidian 安装 Terminal 插件报错的解决方法
问题描述在 Obsidian 中安装 Terminal 插件后，反复弹出以下报错： Terminal resizer exited unexpectedly: 9009 排查过程根据 Deepseek 的提示，使用 Ctrl + Shift + I 打开 Obsidian 开发者控制台，查看详细的错误日志，发现根本原因是 Python 环境问题。 解决方案 卸载现有的 Python，清理残留环境 按照 Terminal 插件仓库的官方文档，重新安装 Python 及其他推荐的依赖项 按照上述步骤操作后，问题完美解决 ✅ 小结如果你在 Obsidian 中遇到 Terminal 插件的 9009 错误，大概率是本地 Python 环境配置有问题。建议： 善用 Ctrl + Shift + I 打开开发者工具查看具体报错 严格按照插件仓库的官方文档安装所需依赖 遇到环境类问题时，干净卸载后重装往往是最高效的解决方式
2026 稳定自用老牌机场推荐
写在前面这几年因为学习、工作和个人兴趣的原因，我长期需要一个稳定、速度可靠的网络环境。机场用过不少，也踩过一些坑，这篇文章简单记录一下我近几年实际长期使用下来体验比较好的几个选择。 本文仅为个人使用经验分享，不构成任何购买建议。 我选择机场时主要看哪些点在选机场之前，我通常会关注以下几点： 运营时间：优先选择运营时间较长的机场，小机场跑路风险较高 稳定性：高峰期是否频繁掉线 速度：是否能满足日常浏览 / 下载 / 视频需求 价格与性价比：价格合理，长期使用成本可控 使用体验：面板、订阅、节点切换是否方便 使用体验较好的几个机场（排名不分先后） 1️⃣ GLaDOS（稳定老牌 / 长期主力）一句话定位：👉 老牌稳定、适合长期使用的主力机场 机场运营时间：约 10 年个人使用时间：约 3 年适合人群：日常使用 / 稳定优先 / 不想频繁折腾 ✅ 优点 老牌机场，2016 年开始运营，长期稳定，不失联、不跑路 节点覆盖较广，日常使用稳定，高峰期波动相对较小 支持多地区流媒体，满足日常浏览和视频需求 ...
