电脑24小时开机电费扛不住？这套300元的远程方案，让你随时随地开关机

作为一个经常需要远程维护家里电脑和NAS的技术爱好者，我经历过太多远程控制的"坑"：

• 米家开机卡：用了两年，断电后经常无法开机，联网也不稳定
• 向日葵开机插座：经常掉线，关键时刻连不上
• ToDesk/向日葵远程桌面：24小时开机电费扛不住，每月多花50块
• 不关机+远程软件：噪音、功耗、硬件寿命都是问题

直到最近接触到KVM over IP技术，我才发现原来还有更优雅的解决方案。今天这篇文章，我会把折腾过的10种方案全部分享给大家。

一、软件远程桌面：日常使用首选

软件远程桌面是最普及的远程控制方式，通过捕获屏幕画面、压缩传输、远程注入键鼠操作实现控制。但各方案差异很大：

商业方案实测数据

最佳实践：Tailscale + RDP

经过反复测试，我发现Tailscale组网 + Windows RDP是当前个人远程桌面的最佳组合：

• 零成本：Tailscale免费版支持100台设备，RDP是Windows自带功能
• 低延迟：P2P直连，鼠标键盘响应几乎无延迟
• 高安全：端到端加密，RDP无需暴露3389端口到公网
• 简单易用：两端装Tailscale，用虚拟IP直接RDP连接

"使用Tailscale内网穿透+RDP远程控制足够日常使用；办公文档、网页浏览画质清晰流畅，鼠标键盘响应延迟极低。"

二、KVM over IP：BIOS级控制的终极方案

软件远程桌面有个致命缺陷：操作系统死机、蓝屏、断电恢复后完全无法介入。这时候就需要KVM over IP了。

什么是KVM over IP？

KVM（Keyboard-Video-Mouse）over IP通过网络传输音视频和控制信号，实现跨地域的BIOS级底层控制。即使电脑蓝屏、进BIOS、重装系统，你都能远程操作。

商业 vs 开源：价格差10倍！

传统商业KVM（ATEN、Raritan等）入门价就要3000元以上，企业级产品更是破万。但开源方案PiKVM把成本打到了250-400元，只有商业方案的1/10！

PiKVM硬件清单：

• 树莓派 4B / Zero 2W：约200元
• HDMI采集卡：约50元
• 电源适配器：约30元
• USB/HDMI线材：约20元
• 3D打印外壳（可选）：约30元

总计：约330元，不到商业KVM的一个零头。

国产新锐选择

如果你不想折腾DIY，这些国产成品也很值得考虑：

三、远程开机：四种方案怎么选？

远程开机是远程控制的第一步，也是最容易被忽视的环节。我测试了四种主流方案：

方案1：智能插座 + BIOS来电自启（首选）

原理： BIOS设置"断电恢复后电源开启"，智能插座通电即开机。

优点：

• 最简单可靠，30-50元搞定
• 向日葵C1Pro、小米智能插座3都可以
• 4G版插座（如向日葵C4）可脱离WiFi使用

缺点：

• 依赖主板支持该BIOS选项
• CMOS电池失效可能导致设置丢失

方案2：PCIe开机卡（进阶选择）

原理： 插在主板PCIe插槽，通过云端控制电源通断。

优点：

• 可开关机、重启，相当于在线的物理电源按钮
• 米家开机卡可接入米家App，实现智能家居联动

缺点：

• 需拆机安装，部分小机箱兼容性差
• 价格50-100元

方案3：手指机器人（无需拆机）

纯物理外挂，粘贴在电源按钮上，通过App控制机械臂按压按钮。优点是不拆机、不改BIOS、兼容任何设备；缺点是成本最高（200-300元），机械结构可能老化。

方案4：WOL网络唤醒（技术玩家）

零成本但配置最繁琐，需要BIOS、网卡驱动、路由器端口转发全部正确配置。适合喜欢折腾的技术玩家。

我的推荐组合： 智能插座（兜底）+ PCIe开机卡（主力）+ WOL（备用），总成本80-150元

四、分阶段实施路线图

根据你的预算和技术水平，我建议分四个阶段逐步实施：

完整方案总成本：¥300-500
一次性投入，长期使用，每月电费从50元降至10元以内

五、注意事项

安全性

• RDP通过Tailscale访问时，无需暴露3389端口到公网，安全性极高
• KVM over IP可完全控制电脑，务必启用双因素认证、限制访问IP
• 智能插座选择正规品牌，避免电气安全隐患

兼容性

• RDP功能仅在Windows专业版/企业版中可用，家庭版需升级
• 并非所有主板都支持"来电自启"功能，购买前需确认BIOS选项
• PiKVM需要配合内网穿透使用，建议直接接入Tailscale网络

电费对比

总结

折腾了这么多方案后，我的最终结论是：

1. 日常远程办公：Tailscale + RDP，零成本、低延迟、高安全
2. BIOS级控制：PiKVM（极客）或向日葵Q1（小白），250-300元
3. 远程开机：智能插座兜底 + PCIe开机卡主力，80-150元

总成本控制在300-500元，兼顾稳定性、功能性和经济性。这套方案我已经稳定运行了两个月，再也没有遇到过远程连不上的尴尬。

如果你也有远程控制的困扰，不妨从Tailscale开始，逐步搭建属于自己的远程管理体系。有问题欢迎在评论区交流！

追梦学习库 · 专注技术分享
转载请联系授权

我用 WorkBuddy 当「全能运维助理」，自建站、NAS、Docker、写文章，一个人全干了

一个人就是一支队伍——告别「五六个工具来回切」的折腾日子。

先说说我过去是怎么干的

作为一个爱折腾自建站的人，我电脑里的工具栏常年是这样：

• 想搭个博客？先装个 WordPress 或者 typecho，再去研究 LNMP 环境
• 想换个域名？打开阿里云、腾讯云、Cloudflare，DNS 解析改来改去
• NAS 上想跑个新服务？SSH 进去 docker run 一通，yaml 文件改到眼花
• 想写篇文章发博客？本地 markdown 写好，scp 上传到服务器，再登录后台发布
• 日常查问题、看文档、写代码，还要切到 Claude / ChatGPT / 各种工具

五个屏幕，七八个软件，十几个标签页。 每次想干个事，光是「把工具备齐」就花掉半小时。

直到我遇到了 WorkBuddy。

WorkBuddy 是什么？

一句话：腾讯出品、能直接替你动手干活的全场景 AI 办公工作台。

跟普通的 AI 对话工具最大的不同是——它不只是给建议，它真的能执行。

更狠的是，它完美连接腾讯办公生态——腾讯文档、腾讯会议、微信、腾讯乐享知识库等都是它的原生搭档。

它有 4 大核心能力：

1. 理解自然语言 —— 不用记命令，一句话下达任务
2. 自主规划执行 —— 它会自己拆解任务、规划步骤、动手操作
3. 多模态任务处理 —— 文档、表格、PPT、数据分析都能干
4. 本地文件操作 —— 读取你授权的文件夹，批量处理

它不是一个聊天机器人，是一个能交付结果的助理。

解决我的实际痛点

下面这些场景，我敢说每一个折腾过自建站的人都中过招。

痛点一：想搭个博客，环境配置劝退 90% 的人

你有没有过这种时刻：看到别人漂亮的技术博客心动不已，自己也想搞一个，结果搜到「如何部署 typecho」的第一篇文章就劝退了——LNMP 是什么？PHP 版本选哪个？Nginx 反向代理怎么配？MySQL 数据库密码忘了怎么找回？

过去我的解决方案：要么花钱买虚拟主机（贵，且不自由），要么对着教程一行一行敲命令（容易报错，且记不住）。

用 WorkBuddy 之后：

"帮我部署一个 typecho 博客系统，Nginx + PHP 7.4 + MySQL 5.7，部署到我的云服务器上。"

它会自动：

• 检查服务器环境
• 安装缺失的依赖
• 下载 typecho 源码
• 配置 Nginx 站点
• 创建数据库
• 跑通安装流程
• 给你一个可以直接访问的 URL

我只需要告诉它我要什么，它来搞定怎么实现。

emlog、WordPress、Typecho、Ghost、Hugo……不管是 PHP 博客还是静态博客，WorkBuddy 都能按你给的框架部署。

痛点二：申请了域名，DNS 解析折腾两天

域名买好了，服务器也有了，但域名怎么指向服务器？ 这是个看似简单实则坑多的问题。

• A 记录、CNAME、AAAA、MX、TXT……每种记录什么意思？
• 在哪改？域名注册商、Cloudflare、还是服务器商？
• TTL 多少合适？什么时候生效？
• 想配个泛域名解析怎么搞？
• 想要 CDN 加速怎么接入？

过去我每次配 DNS 都要 Google 半天。

用 WorkBuddy 之后：

"我在腾讯云买的域名 xxx.com，服务器 IP 是 1.2.3.4，帮我把 www.xxx.com 解析到服务器，同时给根域名也加一条记录。"

它会直接帮你把解析记录配好，还会在文档里给你解释每条记录的作用，顺便告诉你怎么验证解析是否生效。

痛点三：买域名这件小事，没人给我讲清楚

新手第一次买域名大概率踩坑：

• 选哪个后缀？.com 贵但值钱，.cn 便宜但要备案，.me 适合个人博客
• 在哪买？阿里云、腾讯云、NameSilo、Cloudflare、Porkbun
• 续费多少钱？有的首年 9 块第二年 99 块，巨坑
• 实名认证怎么搞？信息填错了怎么改？
• 要不要备案？什么情况下要备案？

用 WorkBuddy 之后：

"我想给我的技术博客买个域名，预算 50 块以内，要好记、有意义，给我推荐几个后缀和注册商，顺便告诉我怎么避坑。"

它会根据你的需求、预算、用途给出一个详细的对比清单——不是干巴巴的官方介绍，是基于实际经验整理的建议。备案不备案、实名认证怎么弄、续费价格怎么对比，全都给你说清楚。

痛点四：NAS 上跑了一堆服务，出问题找不到人问

我的 NAS 上跑了：Jellyfin（影音）、qbittorrent（下载）、Immich（相册）、若干个自建 Web 服务……

服务多，问题就多：

• 这个服务端口冲突了怎么办？
• 怎么把 NAS 上的服务暴露到公网又保证安全？
• Docker Compose 写错了起不来，怎么调试？
• 数据备份怎么做？3-2-1 备份策略怎么落地？
• 想给服务加个 HTTPS 证书怎么搞？

过去我每次遇到问题都去 B 站、知乎、博客园搜，搜出来的答案还经常是过时的或者不适配我用的镜像。

用 WorkBuddy 之后：

"我的 NAS 上跑了个 Jellyfin，但是局域网其他设备访问不到，帮我排查一下问题。"

它会根据你提供的环境信息（Docker 网络配置、路由器设置、防火墙规则等）一步步帮你定位问题。不是给你一段通用教程，是针对你给的配置给出具体建议。

痛点五：Docker 部署，看着简单实则全是坑

docker run 一行命令起一个容器看起来很简单，但实际生产环境：

• 数据持久化怎么做？volume 挂载路径怎么规划？
• 多容器协作怎么编排？docker-compose.yml 怎么写？
• 容器之间怎么通信？网络模式选 bridge 还是 host？
• 镜像怎么选？latest 标签的坑你踩过吗？
• 容器日志怎么管理？容器异常退出怎么自动重启？
• 怎么用 Portainer 可视化管理？

用 WorkBuddy 之后：

"帮我写一个 docker-compose.yml，要求：Jellyfin + qBittorrent + Nginx 反向代理，数据持久化到 /data 目录，自动重启，配置好容器间通信。"

它会直接给你一个生产可用的 compose 文件，注释清楚每一段配置的作用，还可能顺带提醒你：「这里建议加上健康检查」「这里建议给容器加个资源限制」。

这不是 ChatGPT 那种"生成一个看起来对但跑不起来的 yaml 文件"，是基于你需求场景给出的实战方案。

痛点六：想坚持写技术博客，但「写」本身就劝退

写博客这件事，难的不是写作本身，是「凑齐所有条件」：

• 选题：写什么？
• 找资料：去 Google、Stack Overflow、官方文档翻半天
• 写代码示例：要本地能跑起来
• 排版：标题、代码块、图片、引用
• 发布：写完怎么传到博客？博客怎么配置？
• 推广：写了没人看怎么办？

用 WorkBuddy 之后，写博客变成了一件纯粹的事：

"帮我写一篇关于 'Docker 网络模式详解' 的技术博客，目标读者是有一定 Docker 基础的后端工程师，3000 字左右，要有代码示例和配图建议。"

它会直接给你一篇结构完整、代码可跑、有图示建议的技术长文。然后你可以说：

"把这篇文章发布到我的 typecho 博客上，配图帮我用 mermaid 渲染。"

它会去调用对应的工具，把文章推到你的博客。

选题、写作、发布，整个链路你都不用离开 WorkBuddy。

痛点七：文档、报告、PPT、写周报——杂事太多太杂

除了写技术博客这种「硬输出」，日常还有大量「软输出」：

• 写周报：本周做了什么、下周计划、数据汇总
• 写会议纪要：录音转文字 → 提炼要点 → 结构化输出
• 写需求文档：用户故事、功能列表、流程图
• 写技术方案：架构选型、接口设计、风险评估
• 写投标书、合同附件、对外汇报材料
• 整理 Excel 数据：去重、聚合、画图表

WorkBuddy 把这些杂事全包了，而且它跟腾讯办公生态深度集成：

• 文档直接写进腾讯文档
• 表格用腾讯文档的电子表格
• PPT 也能直接生成
• 重要资料沉淀到腾讯乐享知识库
• 微信里发现的问题截个图发给它，它直接帮你处理

真正的"一句话出活"。

痛点八：信息分散，工具割裂

最后说一个不那么显眼但最折磨人的痛点：信息分散、工具割裂。

我以前的工作流是：

• 想法在脑子里 / 微信聊天记录里
• 任务在 Todoist 里
• 笔记在 Notion / 语雀里
• 代码在 GitHub 里
• 服务器操作在 SSH 终端里
• 文档在腾讯文档里
• 沟通在飞书 / 微信里
• 学习资料在浏览器书签里

每个工具都好用，但工具之间的切换是巨大的认知消耗。

WorkBuddy 解决的是「以任务为中心」而不是「以工具为中心」的工作方式。

你要做的只是告诉它你要完成什么——搭博客、写文章、查问题、生成报告——它会调度合适的工具、合适的资源、合适的流程来交付结果。

你不再是工具的「操作员」，你是任务的「决策者」。

总结一下：WorkBuddy 到底能干什么？

一句话：它是你的全能 AI 助理，办公、自建站、内容创作、技术运维，一站式搞定。

怎么开始用？

第一步：扫码下面海报里的二维码 / 点击链接，注册 WorkBuddy
第二步：新建一个任务，描述你想干的事
第三步：看着它干活
第四步：交付可验收的结果

注册还能白拿 2000 积分（积分可以换高级模型调用次数、AI 算力等）。

📎 立即体验 WorkBuddy：

👉 https://www.codebuddy.cn/events/invite?inviteCode=eglb49huxkx30nj

扫码下方海报，立即注册 WorkBuddy，即可获取 2000 积分 👇

WorkBuddy 是一款由腾讯出品的全场景 AI 办公工作台，完美连接腾讯办公生态，是你的办公好搭子。

绿联 NAS Docker 部署 · 扔掉 CF Tunnel · 一行命令公网访问 · 支持自定义域名 · 免费 HTTPS

背景

我之前用绿联 NAS 的 Docker 部署了 Cloudflare Tunnel，把家里的服务通过自己的域名暴露到公网。但 CF Tunnel 在国内环境下频繁掉线——QUIC 协议被运营商掐、NAT 超时回收、Docker 容器动不动就断连。日志里全是：

WRN Failed to dial a quic connection error="timeout: no recent network activity"
ERR Connection terminated

折腾了好几轮 --protocol http2、restart: always、健康检查……治标不治本。

后来发现 Tailscale Funnel 才是正解。它直接复用你已经跑通的 Tailscale 网络底座，一行命令把服务暴露到公网，自带 HTTPS 和自定义域名绑定，彻底甩掉 CF Tunnel 这个不稳定因素。

这篇教程完整记录从迁移到上线的每一步。

前置条件

• 绿联 NAS 已部署 Tailscale（Docker 或套件版均可）
• Tailscale 已登录，设备在线
• 有一个自己的域名，DNS 托管在任意服务商
• NAS 上的服务正常运行（假设跑在 8080 端口）

第一步：确认 Tailscale 正常工作

SSH 登录 NAS，检查 Tailscale 状态：

tailscale status

应该能看到你的 NAS 设备在线，记住它的 Tailscale IP（形如 100.x.x.x）。

如果是 Docker 部署的 Tailscale：

docker exec tailscale tailscale status

第二步：启用 HTTPS 证书

Funnel 需要 TLS 证书。Tailscale 可以自动签发 Let's Encrypt 证书：

tailscale cert --cert-file /tmp/ts-cert.pem --key-file /tmp/ts-key.pem

如果是 Docker 部署：

docker exec tailscale tailscale cert \
  --cert-file /tmp/ts-cert.pem \
  --key-file /tmp/ts-key.pem

这一步 Tailscale 会自动完成域名验证，无需手动操作 DNS。

第三步：开启 Tailscale Funnel

假设你的服务跑在 NAS 的 8080 端口，一行命令暴露：

# 先开启 serve（HTTPS 反向代理）
tailscale serve --bg --https=443 8080

# 再开启 funnel（公网访问）
tailscale funnel 8080 on

Docker 环境：

docker exec tailscale tailscale serve --bg --https=443 8080
docker exec tailscale tailscale funnel 8080 on

现在已经可以通过 https://你的NAS主机名.tailnet名称.ts.net 从公网访问了。

第四步：绑定自定义域名

Funnel 默认用的是 Tailscale 的 ts.net 域名，但你可以绑定自己的域名（例如 sub.example.com）：

4.1 在 Tailscale Admin Console 添加域名

1. 打开 https://login.tailscale.com/admin/dns
2. 点击 HTTPS Certificates 标签
3. 点击 Add a custom domain
4. 输入你的域名，例如 sub.example.com
5. 页面会显示一组 TXT 验证记录

4.2 在域名 DNS 服务商添加 TXT 记录

去你的域名 DNS 管理后台（如 Cloudflare、阿里云 DNS、DNSPod），添加两条记录：

4.3 等待验证

回到 Tailscale Admin Console，点击 Verify。通常几分钟内生效。验证通过后，证书会自动签发。

4.4 配置 Funnel 使用自定义域名

验证通过后，指定域名重新启用 Funnel：

# 先关闭之前的 funnel
tailscale funnel 8080 off

# 用自定义域名重新开启
tailscale serve --bg --https=443 --set-path / 8080
tailscale funnel --bg --set-path / 8080 on

Docker 环境：

docker exec tailscale tailscale funnel 8080 off
docker exec tailscale tailscale serve --bg --https=443 --set-path / 8080
docker exec tailscale tailscale funnel --bg --set-path / 8080 on

第五步：DNS 解析到 Tailscale IP（关键）

到你的域名 DNS 管理后台，添加一条 A 记录：

⚠️ 注意：这一步是把域名指向 Tailscale IP，不是指向公网 IP。只有加入你 Tailnet 的设备能通过域名访问。如果需要完全公网访问，直接用 Funnel 自带的 ts.net 域名即可，不需要这一步。

第六步：验证

# 在任意设备上测试
curl -I https://sub.example.com

# 或用浏览器直接打开
# https://sub.example.com

看到 HTTP/2 200 就是成功了。

停掉旧的 Cloudflare Tunnel

既然 Tailscale Funnel 已经跑通了，可以停掉 CF Tunnel 容器：

docker stop cloudflared
docker rm cloudflared

不再需要维护这个不稳定的隧道了。

Docker Compose 长期运行配置

如果你想让 Funnel 在 Docker 里持久化运行，在当前运行 Tailscale 的容器里，serve 和 funnel 命令加了 --bg 就会后台常驻。Tailscale 容器本身已经设了 restart: always，重启 NAS 后 Funnel 也会自动恢复。

不需要额外容器。

常见问题

Q: Funnel 跑起来后，从外网访问很慢？

Funnel 走 Tailscale 的 DERP 中继节点，速度取决于中继节点的位置。国内访问一般可以接受，但如果你的服务是流媒体/大文件传输，Funnel 不适合（Tailscale ToS 也禁止）。

Q: 自定义域名只能 Tailnet 内访问？

对。如果你把域名 A 记录指向 Tailscale IP（100.x.x.x），只有加入你 Tailnet 的设备能解析和访问。如果需要完全公网访问，直接用 Funnel 分配的 ts.net 域名，自动对全网开放。

Q: 和 Cloudflare Tunnel 比，少了什么？

Funnel 没有 CDN 缓存、没有 WAF、没有 DDoS 防护。但换来的是稳定不掉线。对于个人 NAS 服务来说，稳定比这些附加功能重要得多。

Q: 免费版有流量限制吗？

Tailscale 免费版 Funnel 没有明确的流量硬限制，但 ToS 禁止跑流媒体和大量文件传输。个人 Web 服务、Dashboard、API 完全够用。

总结

CF Tunnel 在国内就是一个大坑，Tailscale Funnel 才是 NAS 玩家正确的公网暴露方式。

本文基于绿联 NAS + Docker + Tailscale v1.80+ 撰写，功能以官方最新版本为准。

家里有台"高算力电脑"却只能在公司干瞪眼？用 Marvis 远程调用本地模型+操控浏览器

不用装 TeamViewer、不用开 AnyDesk 会员、不用背电脑上下班——一个 Marvis，让家里的高性能电脑随时随地听你指挥。

我的困境：一台"被困在家里的算力怪兽"

先说说我的情况。

我自己攒了一台配置还不错的主机放在家里：i7-13700K、RTX 4090 24GB、64GB 内存。平时在家用它跑 Ollama 部署的本地大模型（Qwen2.5、DeepSeek-R1 这些），做点 AI 应用开发和测试，流畅得飞起。

但问题是——我白天大部分时间不在家。

在公司用着轻薄本写文档、开会、处理杂事，想到家里的"算力怪兽"就心痒：要是能在公司用手机指挥家里的电脑跑模型推理、帮我做浏览器自动化任务、甚至管理我部署在本地的小网站，该多好？

试过几款远控软件：

• AnyDesk 免费版传文件卡成 PPT
• TeamViewer 各种弹窗催你买商业版
• ToDesk 画质糊得看不清命令行输出
• 向日葵……懂的都懂

而且上面这些工具都只是"远程桌面"——你得盯着屏幕、拖着鼠标一点一点操作。有没有办法一句话就让电脑干活？

还真有。它就是 腾讯 Marvis。

Marvis 是什么？

一句话概括：Marvis 是腾讯推出的操作系统层级个人 AI 助手，它能用自然语言操控你的电脑——管理文件、操作软件、配置系统、甚至跨设备远程控制。

最打动我的一点：它支持手机端远程操控电脑。不是那种"看着桌面用手戳"的传统远控，而是你在手机上发一句话，电脑端自动执行任务，然后告诉你结果。

这就意味着：我可以随时随地"使唤"家里的高算力电脑，而不需要时刻盯着屏幕。

场景一：移动端一句话，远程跑本地大模型

场景是这样的：我在公司开会，同事突然讨论到"能不能用本地模型跑一下这段长文本的情感分析？"

放在以前，我只能说"等我晚上回家试试"——然后就没有然后了。

现在？掏出手机，打开 Marvis App（和 PC 端用同一个微信登录），选中家里那台电脑，输入：

"帮我在电脑上打开 Ollama，用 qwen2.5:14b 模型分析 D 盘 Work 文件夹里那个 customer_reviews.txt 文件，把正面评价、负面评价、中性评价分类统计出来，生成一份 Markdown 报告放到桌面。"

Marvis 收到指令后，家里的电脑开始自动执行：启动终端 → 调用 Ollama → 读取文件 → 运行推理 → 输出报告。几分钟后，手机端弹出通知："任务已完成，报告已保存至桌面。"

整个过程中我没碰一下键盘鼠标，甚至不需要开着电脑远程桌面——Marvis 帮我搞定了全部。

这就是 "一句话远控" 和传统远程桌面的本质区别：你只需要描述结果，不需要亲自操作每一步。

场景二：手机操控浏览器，自动化运维个人网站

我的个人博客和几个小项目部署在家里的 Homelab 上，偶尔需要更新内容、检查 SSL 证书、或者重启 Nginx 服务。

以前每次改点什么东西，都得正襟危坐打开电脑 SSH 进去。现在我直接在手机上给 Marvis 发指令：

"帮我在电脑上打开浏览器，访问 https://我的网站.com 看看能不能正常打开。如果访问不了，检查一下 Nginx 状态和 SSL 证书有效期，有问题帮我修复。"

Marvis 会自动打开 Chrome → 访问网址 → 检查页面状态 → 如果打不开，就去检查 Nginx 服务状态和证书信息 → 告诉我哪里出问题了，等我确认后再执行修复。

还有一次，我需要批量抓取几个竞品网站的页面标题和 meta 描述做分析。以前这种浏览器自动化任务我得写 Python 脚本，现在只需要：

"帮我打开浏览器，依次访问这几个网站：[网址列表]，把每个网站的标题、描述、以及首页有哪些主要功能模块，整理成一个表格保存到桌面。"

几分钟后表格就生成好了。这种浏览器自动化 + 跨端远程的组合，对于需要远程管理网站、做竞品分析、甚至是远程维护服务器的人来说，效率提升不是一点半点。

场景三：出差途中，远程调取家里的开发环境

作为经常折腾各种 AI 项目的开发者，我的台式机上配置了完整的 Python 环境、CUDA 依赖、各种模型文件。出门在外想改段代码、跑个测试，我的轻薄本完全扛不住。

有了 Marvis，我在酒店用 iPad 就能远程"使唤"家里的电脑：

"帮我在电脑上打开 VS Code，打开 D 盘 Projects/ai-chatbot 这个项目，把 app.py 里第 45 行的 temperature 从 0.7 改成 0.3，保存后重启服务，然后告诉我新的访问地址。"

Marvis 会依次完成：打开 VS Code → 定位文件 → 修改参数 → 保存 → 重启服务 → 输出新的本地访问地址。

这就是我梦想中的远程工作方式——不是远程操控一台电脑，而是远程"指挥"一个智能助手帮我操作电脑。

安全吗？我的数据和操作谁来兜底？

说实话，一开始我也担心：让 AI 直接操控我的电脑，会不会把我的文件搞乱？

Marvis 在这方面的设计让我比较放心：

1. 敏感操作强制确认：涉及删除文件、修改系统配置、支付等操作时，Marvis 会弹出"硬确认"提示，必须我亲自点击确认才会执行，不会自作主张。
2. 本地模式，数据不出设备：如果处理的文件涉及敏感数据（比如个人证件、财务表格），可以切换到本地模式。在这种模式下，文件处理完全在本地端侧模型上运行，拔掉网线也能正常使用，数据物理上不会离开你的电脑。
3. 授权范围可控：你可以自定义 Marvis 的文件索引范围，不想被 AI 碰到的文件夹可以排除在外。

其他顺手好用的场景

用了 Marvis 一段时间，除了上面这些"硬核"场景，还有一些日常小功能也很好用：

• 下班忘存档：在地铁上想起游戏没存档，手机发一句"帮我检查星露谷存档并退出游戏"，回家继续玩。
• 远程帮父母修电脑："帮我看一下我爸电脑上的打印机为什么连不上了"，省去电话里教半小时的折磨。
• 临时要文件：老板找你要方案，而方案在另一台电脑上——手机一句"把桌面上 XX 方案发到我手机上"，搞定。

怎么用？

1. 访问官网 https://marvis.qq.com 下载 PC 客户端（支持 Windows/Mac）和手机 App（iOS/安卓）
2. PC 端和手机端用同一个微信或 QQ 登录
3. 手机端按提示完成授权，连接对应的 PC 设备
4. 在手机端新建会话，左上角选择已连接的电脑，开始用自然语言发任务

💡 小提示：初次使用需要等待 Marvis 对本地文件建立索引。文件多的话建议晚上挂机让它在低资源模式下慢慢跑，不影响正常使用。

写在最后

Marvis 解决的不是"怎么远程控制电脑"这个问题——市面上远控软件太多了。它解决的是"如何让远程电脑替我干活，而不是让我远程盯着它干活"。

对于家里有高算力电脑、需要执行浏览器自动化、管理个人网站、或者单纯不想背着沉重笔记本通勤的人来说，这种"一句话让电脑自己动"的体验，用一次就回不去了。

目前 Marvis 完全免费，每个账号每天有 1000 万 token 额度，常规操作大部分消化在本地端侧算力上，实际消耗很少。感兴趣的朋友可以下载体验一下。

🔗 官网下载：https://marvis.qq.com

📱 支持 Windows / macOS / iOS / Android

Marvis

本文基于 Marvis 实际使用体验撰写，功能以官方最新版本为准。

记一次 Emlog Docker 部署后全站 404 的排查与解决

分类：建站运维 · 标签：Emlog、Docker、1Panel、伪静态、Apache

最近用 Docker 在服务器上部署了一个 Emlog 博客，配合 1Panel 面板和 OpenResty 反向代理。容器跑起来之后，访问首页直接返回一个 Apache 的 404 页面：

Not Found
The requested URL was not found on this server.
Apache/2.4.54 (Debian) Server at www.你的域名 Port 80

奇怪的是，容器明明是运行状态，数据库也连上了，但就是打不开。折腾了一番才找到根因，这里把完整的排查思路和解决方法记录下来，给遇到同样问题的朋友一个参考。

一、我的部署环境

先交代一下环境，方便对照：

• 博客程序：Emlog Pro（Docker 容器部署）
• 镜像：emlog/emlog:pro-latest-php7.4-apache
• 面板：1Panel
• Web 服务：OpenResty（反向代理到容器）
• 数据库：MySQL 容器
• 端口映射：宿主机 8080 → 容器 80
• 数据挂载：宿主机数据目录 → 容器 /app

请求链路是这样的：用户 → CDN → OpenResty → Docker Emlog 容器（Apache + PHP）→ MySQL。

二、排查过程

1. 先确认容器在不在

容器名可能因为重建而变化，所以第一步先看实际容器名：

docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"

确认容器确实在运行，名字也记下来（下文用 emlog容器 代指）。

2. 检查伪静态模块

Emlog 的伪静态依赖 Apache 的 mod_rewrite，先确认它启用了：

docker exec emlog容器 apache2ctl -M | grep rewrite

输出 rewrite_module (shared)，说明模块没问题。

3. 关键发现：DocumentRoot 指向了空目录

接着看 Apache 的站点配置：

docker exec emlog容器 apache2ctl -S 2>&1 | head -20

输出里有一行：

Main DocumentRoot: "/var/www/html"

再去看这个目录里有什么：

docker exec emlog容器 ls /var/www/html/

结果是空的，什么都没有。

那 Emlog 的文件到底在哪？全局搜一下 index.php：

docker exec emlog容器 find / -name "index.php" -not -path "*/usr/share/*" 2>/dev/null

输出里能看到 Emlog 的程序文件其实在 /app 目录下：

/app/index.php
/app/admin/index.php
/app/content/...

到这里问题就清楚了。

三、问题根因

这个 Emlog Docker 镜像有一个设计上的坑：

Apache 默认的站点配置 000-default.conf 里，DocumentRoot 指向的是 /var/www/html，但 Emlog 的实际程序文件放在了 /app 目录。/var/www/html 是一个空目录，所以无论访问什么路径，Apache 都找不到文件，统统返回 404。

雪上加霜的是，Apache 默认配置里所有 Directory 块的 AllowOverride 都是 None。这意味着即使你放了 .htaccess 伪静态文件，Apache 也根本不会去读它。

所以要让站点正常访问、伪静态生效，必须同时解决两个问题：

1. 把 DocumentRoot 指向正确的 /app 目录
2. 开启 AllowOverride All，让 .htaccess 生效

四、解决方案

第一步：准备 .htaccess 文件

Emlog 的数据目录是挂载到容器 /app 的，所以直接在宿主机的数据目录里创建 .htaccess 即可：

cat > /你的数据目录/.htaccess << "EOF"
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
EOF

第二步：准备自定义站点配置

在宿主机上写一个 Apache 站点配置文件，把 DocumentRoot 指向 /app 并开启 AllowOverride：

mkdir -p /opt/emlog/conf

cat > /opt/emlog/conf/emlog-site.conf << "EOF"
<VirtualHost *:80>
    DocumentRoot /app
    <Directory /app>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>
EOF

第三步：用 docker run 重建容器

这里要特别注意：不要用 1Panel 的图形界面去改挂载，它会报一个莫名其妙的错误：

includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed

这是 1Panel 把挂载路径当成了 Docker 的命名卷（named volume）而不是 bind mount。直接用 docker run 手动建容器最稳妥：

docker run -d \
  --name emlog容器 \
  --restart always \
  -p 8080:80 \
  -v /你的数据目录:/app \
  -v /opt/emlog/conf/emlog-site.conf:/etc/apache2/sites-enabled/000-default.conf \
  emlog/emlog:pro-latest-php7.4-apache

注意：.htaccess 要放在 /app 目录下（也就是宿主机的数据目录里），不要挂载到 /var/www/html/.htaccess，那个目录是空的，挂了也没用。

第四步：配置 OpenResty 伪静态

在 1Panel 里找到对应站点 → 站点设置 → 伪静态，填入：

if (!-e $request_filename) {
    rewrite ^/(.*)$ /index.php last;
}

如果面板的伪静态入口对反向代理站点不生效，就手动编辑 OpenResty 配置，在 location / 之前加入 rewrite 规则：

server {
    listen 80;
    server_name 你的域名 www.你的域名;

    if (!-e $request_filename) {
        rewrite ^/(.*)$ /index.php last;
    }

    location / {
        proxy_pass http://你的服务器IP:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

改完重载 OpenResty：

docker exec openresty容器 nginx -s reload

第五步：Emlog 后台设置

1. 登录 Emlog 后台
2. 进入「设置 → 链接结构」
3. 选择「文件格式」（形如 /post-1.html），SEO 友好
4. 确认「站点地址」填的是你的正式域名（https://你的域名），而不是 http://服务器IP:8080，否则生成的链接会带 IP 和端口
5. 保存

五、一个容易遇到的小插曲：.htaccess 不可写

后台保存链接结构时，可能会提示「根目录下的.htaccess不可写」。

原因是 .htaccess 是用 root 创建的，而容器里 Apache 的运行用户是 www-data（UID 33），没有写权限。改一下文件归属就行：

chown 33:33 /你的数据目录/.htaccess

还不行就直接放开写权限：

chmod 666 /你的数据目录/.htaccess

其实我们手动放的规则已经是通用的了，Emlog 保存时只是用自带规则覆盖一遍，效果一样。这一步主要是让后台保存不报错，同时把链接结构写进数据库。

六、让配置持久化

上面这套配置都是放在宿主机、通过挂载进容器的，所以容器重建也不会丢。需要持久化的就两个文件：

以后无论容器怎么重建，只要这两条挂载在，伪静态就一直是好的。

七、踩坑总结

把这次踩的坑集中列一下，方便快速对照：

1. DocumentRoot 陷阱：Emlog 镜像的 Apache 默认指向空的 /var/www/html，真实文件在 /app，必须用自定义站点配置覆盖。
2. AllowOverride 默认 None：即使放了 .htaccess 也不生效，必须显式开启 AllowOverride All。
3. 别用 1Panel UI 改挂载：会报 "invalid characters for a local volume name"，直接用 docker run。
4. proxy_pass 别用 127.0.0.1：容器内的 127.0.0.1 指向容器自己，要用宿主机内网 IP。
5. 站点地址要填正式域名：填 IP:端口会导致生成的链接全是 IP。
6. .htaccess 写权限：root 创建的文件 www-data 写不了，记得 chown 33:33。
7. 改完 OpenResty 要重载：否则配置不生效。

八、常用排查命令备忘

最后留一份排查命令清单，下次遇到问题可以按顺序敲：

# 确认容器名
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"

# 检查 mod_rewrite
docker exec emlog容器 apache2ctl -M | grep rewrite

# 查看 DocumentRoot 指向
docker exec emlog容器 apache2ctl -S 2>&1 | head -20

# 检查 .htaccess（注意是 /app 不是 /var/www/html）
docker exec emlog容器 cat /app/.htaccess

# 检查站点配置
docker exec emlog容器 cat /etc/apache2/sites-enabled/000-default.conf

# 确认 Emlog 文件存在
docker exec emlog容器 ls /app/index.php

# 查看挂载情况
docker inspect emlog容器 --format '{{json .Mounts}}' | python3 -m json.tool

# 看 Apache 错误日志
docker exec emlog容器 tail -20 /var/log/apache2/error.log

结语

这次问题的核心，就是 Emlog Docker 镜像的 DocumentRoot 指向和实际文件位置不一致。看似一个 404，背后其实是「DocumentRoot 指错 + AllowOverride 没开」两个问题叠加。把这个坑记下来，希望能帮到同样在用 Docker 部署 Emlog 的朋友。

如果你也遇到了类似的 404，不妨先 apache2ctl -S 看看 DocumentRoot 到底指向哪里，多半问题就出在那。