RackNerd Ubuntu VPS 安装远程桌面：XFCE、xrdp、Chrome 与常见坑记录
这篇记录的是在 RackNerd Ubuntu 24.04 VPS 上搭建一个可从 Windows 远程桌面连接的 Linux 图形桌面环境的完整过程。最终方案是：Ubuntu 服务器上安装 XFCE + xrdp，Windows 端使用系统自带的“远程桌面连接”输入 VPS IP、用户名和密码登录。 这不是把 VPS 变成真正的高性能云电脑。它更适合临时打开网页、调试服务、查看图形界面程序，或者在服务器上完成一些偶尔需要 GUI 的操作。 最终使用的结构最终链路是： 12345Windows 远程桌面连接 -> 107.172.191.70:3389 -> VPS 上的 xrdp -> XFCE 桌面 -> 用户 raymondguo 服务器上同时还跑着其他项目，例如 nginx、Docker、new-api、CLIProxyAPI 等。所以这次桌面环境的处理重点不是“能装上就行”，而是尽量只动桌面相关组件，不影响已有服务。 最终确认过的关键点： 12345nginx 继续监听 80/443new-api 继续只绑定 127.0.0.1:3...
Pinterest 拖入图片到 PureRef 中失败？试试打开 v2rayN 的旧版 TUN 保护
背景最近遇到一个很奇怪的问题：浏览器里 Pinterest 可以正常打开，v2rayN 代理也一直开着，但从 Pinterest 直接拖图片到 PureRef 时就是失败。 这个问题容易让人以为是 Pinterest 的图片链接有问题，或者 PureRef 不支持从 Pinterest 拖图。但后来确认，关键并不在 Pinterest，也不在 PureRef，而是在 v2rayN 的 TUN 相关设置上。 最终解决方法我的处理方式很简单： 重新下载一份干净的 v2rayN。 尽量避免沿用之前长期使用过程中被自己改过很多次的配置。 开启 TUN 模式。 在 TUN 设置里打开 旧版 TUN 保护。 设置位置如下图： 这里最关键的就是这个选项： 1旧版 TUN 保护 对应到配置里，就是： 1"EnableLegacyProtect": true 我之前出问题的配置里，这一项是 false。改成 true 之后，从 Pinterest 拖图片到 PureRef 的问题就解决了。 为什么建议重新下载 v2rayN？因为 v2rayN 用久之后，很容易在排...
PureRef 从 Pinterest 拖图失败：Proxy connection refused 的定位与修复
问题现象今天遇到一个很典型但容易误判的问题：从 Google Images 可以直接把图片拖进 PureRef，但从 Pinterest 拖图到 PureRef 时失败，PureRef 弹出错误： 12Failed opening images.Proxy connection refused (...jpg) 一开始看起来像是 Pinterest 没有走代理，或者 PureRef 不支持 Pinterest 的拖拽链接。但实际排查后发现，根因不是 Pinterest 规则缺失，而是 v2rayN 的系统 PAC 指向了一个没有监听的本地代理端口。 关键区别：浏览器能打开，不代表 PureRef 能下载浏览器访问 Pinterest 正常，只能说明浏览器的代理链路是通的。PureRef 的拖拽逻辑不一定复用浏览器已经加载好的图片数据。 从 Pinterest 拖图时，PureRef 很可能拿到的是图片 URL，例如： 1https://i.pinimg.com/...jpg 然后 PureRef 自己再去下载这张图。这个下载过程会走 Windows 系统代理。如果系统代理...
从 /root 到普通用户：我的 Hexo 博客安全迁移与运维实录
在 Linux 运维的江湖里，有一条不成文的准则：“如无必要，勿用 Root”。今天，我终于对手头那个运行在 Racknerd VPS 上的 Hexo 博客动了刀，将其从传统的 /root 目录彻底迁移到了普通用户 /home/raymondguo 下。 这篇文章将记录这次迁移的技术细节、安全考量，以及我如何利用 Gemini CLI 实现自动化运维的闭环。 1. 为什么要迁移？安全性是第一生产力在 2026 年的今天，网络攻击的手段早已不再局限于简单的暴力破解。如果你的 Web 服务（如 Hexo 生成的静态页面或其构建环境）直接以 Root 身份运行在 /root 目录下，一旦发生由于 Node.js 插件漏洞或配置不当导致的 RCE（远程代码执行），攻击者将直接继承 Root 权限。 迁移的好处： 最小特权原则 (Least Privilege)：普通用户权限有限，即便服务被攻破，攻击者也被困在 /home 的特定目录下。 环境隔离：避免了在 /root 下操作时误删系统核心文件的风险。 符合标准规范：在 Linu...
RackNerd 2026 超高性价比 VPS 全线特惠：最低 $21.99/年，支持支付宝，入门级 VPS 首选
写在前面如果你正在找一台便宜、稳定、能用支付宝付款的入门级 VPS，那么 RackNerd 依然是很值得关注的选择。它不是主打国内优化线路的 CN2 GIA 商家，但在低价 VPS、备用机、学习环境、轻量博客、小脚本和远程测试机这些场景里，性价比一直很能打。 这篇我把当前还能打开订单页的 RackNerd 特价套餐重新整理成表格，并把购买入口统一换成了我的 RackNerd 分销链接。旧活动里已经提示 Out of Stock 的链接已经清理掉，具体库存、机房和最终价格请以打开后的 RackNerd 订单页为准。 核心提示：RackNerd 特价套餐经常会出现“页面能打开，但某些机房或某些配置临时缺货”的情况。我会优先保留当前可进入订单配置页的套餐，后续如果库存变化再继续更新。 我会优先怎么选？ 只想要便宜备用机：目前优先看 $21.99/年的 1G 套餐。 做小博客 / 轻量服务：建议从 2G 内存起步，价格和体验更平衡。 预算更充足：4G、6G、8G 套餐适合跑更多服务，流量也更宽。 下单前再确认：RackNerd 库存变化快，最终以订单页是否能继续...
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...
Obsidian 多个知识库如何共享一套插件文件夹
如果你同时维护多个 Obsidian 知识库，很容易遇到一个重复问题：每个知识库都会各自生成一份 .obsidian/plugins 目录，插件需要分别安装和更新，维护成本很高。 在 Windows 下，一个比较直接的方案是使用符号链接（Symbolic Link），让副知识库的插件目录直接指向主知识库的插件目录，这样两边就可以共用同一套插件文件。 当前目录示例 主知识库插件目录：F:\Raymond_Obsidian\.obsidian\plugins 副知识库插件目录：G:\Hexo_Blog_Raymond\source\_posts\.obsidian\plugins 操作步骤 先删除副知识库中的 .obsidian/plugins 文件夹，只保留主知识库的插件目录。 以管理员身份打开 CMD。 执行下面这条命令，为副知识库创建一个目录符号链接： 1mklink /D "G:\Hexo_Blog_Raymond\source\_posts\.obsidian\plugins" "F:\Raymond_Obsidian\.obsidian...
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 稳定自用老牌机场推荐（持续更新中）
写在前面这几年因为学习、工作和个人兴趣的原因，我长期需要一个稳定、速度可靠的网络环境。机场用过不少，也踩过一些坑，这篇文章简单记录一下我近几年实际长期使用下来体验比较好的几个选择。 本文仅为个人使用经验分享，不构成任何购买建议。 我选择机场时主要看哪些点在选机场之前，我通常会关注以下几点： 运营时间：优先选择运营时间较长的机场，小机场跑路风险较高 稳定性：高峰期是否频繁掉线 速度：是否能满足日常浏览 / 下载 / 视频需求 价格与性价比：价格合理，长期使用成本可控 使用体验：面板、订阅、节点切换是否方便 先按付费方式分一下我现在会把机场先分成两类来看： 按月付费型：适合日常主力使用，订阅稳定、流量每月刷新，比较省心。 按量付费型：适合备用和低频使用，买多少用多少，不用的时候不会一直扣月费，流量永不过期，更适合偶尔应急。 如果你是第一次选，建议优先看按月付费型；如果你已经有主力，只想准备一个备用入口，可以重点看按量付费型。 一、按月付费型机场这类机场更适合长期放在客户端里作为主力或常用备用。优点是使用习惯简单，套餐、订阅、节点更...