起因 第一篇和第二篇都在讲同一件事：在 M 系列 Mac 上用 UTM 跑一台 x86 Windows 7，把一个只有 Windows 客户端的加密 U 盘直通进去解锁。 不管怎么调优，速度的天花板一直没变：从 U 盘读约 2.2 MB/s，往 U 盘写约 1 MB/s。根因在于 M 芯片是 ARM 架构，这台 Win7 是整个操作系统都在逐条翻译 x86 指令。 最自然的出路，就是换成 Windows 11 ARM： 系统本身是 ARM 原生的，在 Mac 上靠硬件虚拟化运行，接近原生速度 只有厂商客户端这一个 x86 程序，交给 Windows 自带的模拟层（Prism）去跑 需要模拟的从「一整个操作系统」变成「一个程序」，理论上能快一个数量级。这篇就是实测这条路。 事先的判断，和一个没核实的风险 Windows on ARM 的模拟有一条硬限制，微软文档写得很清楚：模拟只覆盖用户态程序，不支持驱动；所有内核态组件都必须是 ARM64 原生编译的。 所以关键只有一个问题：这个客户端要不要装自己的内核驱动？ 动手之前，我在 Mac 上对客户端做过一次静态分析： 主程序的导入表里没有创建服务的函数，只有「查询服务状态」 程序里确实有一句「驱动服务启动失败，请联系管理员」，但相邻的代码和字符串都指向一个给 Windows XP 补装 exFAT 文件系统驱动的流程，Win11 本来就自带 exFAT 但主程序里还打包了一个加密过的 DLL，运行时才解开，静态分析看不到里面是什么 当时的结论是「看起来不装内核驱动，可能性比较大，但那个加密 DLL 没法核实」。后来知道了，问题恰恰就出在这个没法核实的地方。 ...

拿着线路保护出口图、断路器保护屏操作箱图、开关机构图，再下到保护室对着端子排一根根看线号，把一条 500kV 线路的跳闸命令从保护出口一路追到了分闸线圈，顺带弄明白了跟跳和失灵。

从“CT 为什么不能开路”出发，拿着手机下到保护室，对着端子排、线号和图纸，把一条 500kV 线路保护的和电流从 CT 出发、穿过保护、安稳、录波再回到 CT 的整圈走通了。

干了几年运维，二次一直是短板。这次给自己定了一棵 52 个知识点的知识树，从最底层的二次回路识图学起。这是第一天的笔记。

起因 上一篇讲了怎么在 M 系列 Mac 上用 UTM 跑一台 x86 Windows 7，把一个只有 Windows 客户端的加密 U 盘直通进去解锁，再把文件传回 Mac。 方案跑通之后用了两周，攒下三个不爽： 解锁之后，加密区要等很久才出现，而且感觉"以前没这么慢" 进了 Windows 桌面，还得回 Mac 再点一次"连接 U 盘" 大文件照旧很慢 这次花了一整天，前后改了十几个版本。三个问题都有了着落，路上还学到一件比技术细节更重要的事：我对同一个崩溃连着误判了三次。下面按顺序讲。 一、加密区出现得慢：一个后台脚本，两个 bug Windows 里常驻着一个我自己写的小脚本：盯着有没有 U 盘插进来，发现厂商客户端就自动启动它，等加密区出现再做后续动作。 问题出在它"盯"的方式。它每 2 秒用 WMI 查询一次所有磁盘，而这个查询会顺带读取每个盘的剩余空间：包括走 WebDAV 的网络盘（当时还处在"脱机"状态，每次都要等超时），也包括刚解锁、正在挂载的加密区。这台 Windows 只有一个模拟出来的 CPU 核，这个查询正好卡在"输完密码 → 加密区挂载"这一段，和系统抢同一个核。 改成只看"盘符表有没有变化"：这个调用不读介质、不走网络，几乎零开销。 顺手查出第二个 bug，比第一个更离谱：这个脚本里的中文从来就没被正确读过。 Win7 自带的是 PowerShell 2.0，用 -File 运行一个没有 BOM 的脚本时，它按系统代码页（中文系统是 GBK）来读 UTF-8 文件，于是： 脚本里写的 PowerShell 2.0 实际看到的 导出到Mac 瀵煎嚭鍒癕ac 所有按中文名找文件夹、认卷标的逻辑都在拿乱码做比较，永远匹配不上。它之前一直"能用"，纯属另一条兜底分支凑巧撑着。之后所有写给 Windows 的脚本统一加 BOM，单元测试也锁住了这一条。 ...

我原来有两台境外 VPS，后来只剩一台。在今天这个大环境下，单点就是不保险：哪天这台机器的 IP 被封，全家就断网。 网上流传着一种「Cloudflare 免费搭 VPN」的方法：不用买服务器，在 Cloudflare Workers 上跑一段脚本就能翻墙。我照着搭了一条，当作家里 Apple TV 看视频的备用线路。 搭起来不难，难的是弄懂它为什么能用。不懂原理，出了问题只能瞎试；懂了原理，哪里慢、哪里不稳、哪里有风险，心里都有数。这篇文章把原理拆开讲清楚，最后附上我踩过的坑和几条使用边界。 文中域名、IP、UUID 均为占位符，请替换成你自己的。 一、先弄清楚「墙」是怎么拦的 在国内直接打开 YouTube，防火墙（GFW）主要用三招拦你： DNS 污染：你问「youtube.com 在哪」，它抢先回你一个假地址； 封 IP：YouTube 服务器的真实 IP 直接不给通； 看 SNI：HTTPS 握手时有个明文字段叫 SNI，写着「我要访问 youtube.com」，它看到就掐断。 所以任何翻墙方案，本质上都在解决一件事：让防火墙看到的东西，既不是被封的 IP，也不是被封的域名，而且看起来像一次正常的上网行为。 二、为什么偏偏是 Cloudflare Cloudflare 是全球最大的 CDN，大约五分之一的网站挂在它上面，其中不乏国内外企业的正常业务。几百万个网站共用它那几段 IP。 如果防火墙把 Cloudflare 的 IP 全封了，会误伤一大片正常网站，代价太大。所以Cloudflare 的 IP 在国内基本是通的，只是经常绕路、慢一点。 这是整个方案的地基：找一个「封不起」的平台，躲在它后面。 三、Workers 是什么，它干了什么 Cloudflare Workers 是一个「在 Cloudflare 全球机房里跑你自己代码」的服务。关键在于，它允许代码主动向外建立 TCP 连接（connect() 接口）。有了这个能力，几千行脚本就能扮演一台代理服务器。社区里最流行的实现是开源项目 edgetunnel。 一次完整的访问是这样走的： 手机 / 电视 Cloudflare 机房 目标网站 ┌───────────────┐ ① HTTPS 连接 ┌──────────────────┐ ③ 普通 TCP ┌──────────┐ │ 代理客户端 │ ────────────────────► │ 你的 Worker │ ──────────────► │ YouTube │ │ 把「我要去 │ 目标 IP：CF 的 IP │ ② 拆包、核对 UUID │ │ │ │ YouTube」装进 │ SNI：你的小域名 │ 读出真正目的地 │ ◄────────────── │ │ │ 加密信封 │ ◄──────────────────── │ ④ 把数据原路送回 │ └──────────┘ └───────────────┘ └──────────────────┘ ▲ 防火墙只看到：有人在用 HTTPS 访问一个挂在 Cloudflare 上的普通小网站 分步说： ...

站里"一键顺控视频双确认"系统用的视频判别主机，9 月上旬黑屏了半个多月。厂家先后寄来一套 DVI 的 KVM、一套 VGA 的 KVM，结论始终是"KVM 坏了"，但说不清为什么坏。最后我们自己一步步排查，发现 KVM 根本没坏，真正的原因是机器里那块独立显卡在断电时"掉线"了。 这篇把整个来龙去脉记下来，包括走过的弯路。敏感信息（IP、端口、账号密码、设备序列号等）都已去掉。 一、设备和接线 先交代清楚这台机器，后面的现象才好理解： 主机：华为 2288H V5 服务器，装的是凝思安全操作系统 V6（Debian 系，内核 4.9，X Server 1.16）； 显卡有两块：一块是主板自带的管理显卡（只有一个 VGA 口），一块是 NVIDIA RTX 2060 独立显卡（DVI、HDMI、DP 口）； 业务：一键顺控视频双确认平台、海康视频对接、AI 识别算法等，大部分跑在 Docker 容器里，另有几个服务和一个"反向隔离"客户端要手动启动； 显示：一路到主控台的显示器（高清），一路到屏柜里的 LED KVM（现场维护用），两边原本同时显示同一个桌面。 原厂的设计是：桌面跑在独显上，独显的两个口分别送到主控台和屏柜。主板那个 VGA 口其实只是个文字控制台。这一点是后来才搞明白的，也是整件事的关键。 二、故障经过和厂家的两次"换 KVM" 9 月上旬，这台主机运行不畅，我们按常规断电重启。重启后主控台和屏柜都只剩黑屏，左上角一个白色光标，进不去图形界面，视频判别功能也停了。 联系厂家后，厂家判断是 KVM 坏了： 第一次：寄来一套 DVI 的 KVM。接上去，还是连不上，没画面； 第二次：我们提出改用 VGA，厂家又寄来一套 VGA 的 KVM。这次接上"能用了"，屏柜能看到东西了，但主控台的高清显示没了，而且只是个勉强能用的状态。 问厂家 KVM 为什么坏，没有答案。现在回头看，第二次"能用"恰恰是个线索：VGA KVM 接的是主板的 VGA 口，绕开了独显；DVI KVM 接的是独显，所以怎么换都不亮。 三、自己排查：先证明系统是活的 1. 看开机过程 我把开机全过程拍成视频逐帧看：BIOS 自检正常，内核正常加载，RAID 卡初始化成功，各分区做了文件系统检查，日志里有"文件系统未正常卸载、自动清除脏位"的字样，说明之前确实有过非正常断电。检查完之后才黑屏。 ...

周日傍晚，我想打开家里的 Emby 看点东西，浏览器却甩给我一个 Cloudflare Error 1033 — Tunnel error。 一个错误页，牵出一整晚的排障、一次彻底的服务迁移，最后以我把一块固态硬盘从 NAS 里拔出来收尾。记下来，既是复盘，也给同样在家折腾 NAS 的人提个醒。 一、第一现场：不是 Emby 的错 1033 是 Cloudflare Tunnel 的错误——问题不在 Emby，而在"隧道的另一头连不上了"。我打开内网的群晖，Container Manager 里一看：十几个容器全是灰点（已停止），只有 immich 的一个还亮着绿灯，写着"已运行 6 小时"。 “只有一个还活着、其余全停”——这个模式很关键。它后来成了整条线索的锚点。 二、排障：先把假设一个个证伪 家里 NAS 出问题，最容易的反应是"重启一下试试"。但重启会毁掉现场，也可能把真正的原因永远盖住。所以我逼自己按纪律来：先提假设，再找能证伪它的证据，别用"症状吻合"直接定罪。 假设一：NAS 重启过，容器没跟着自启。 一条命令就否了： $ uptime up 37 days, ... 开机 37 天，根本没重启。假设一出局。 那是什么时候、以什么方式停的？ 我去翻各个容器数据目录的修改时间，发现一批配置和数据库文件都停在同一分钟——今早 7 点零几分。而且它们是"干净落盘"的（比如 Transmission 只有在正常退出时才会重写它的配置文件）。也就是说：这些容器是在早上 7 点被"优雅地停止"了，不是崩溃。 immich 那个"已运行 6 小时"，正好对得上 7 点这个时间点——它是唯一自己爬回来的。 假设二：是我那个"磁盘温度守护"容器把它们停了。 我之前写过一个小容器，逻辑是"某块盘持续超温就停掉几个吃硬盘的服务保护一下"。看着像是它干的。但翻它的日志，只有早上 7 点零几分的一条温度告警，没有任何"执行保护、停止服务"的记录。按它的逻辑，要"持续超温十分钟"才会动手停容器——而它自己在报警几秒后就跟着一起被停了，根本没来得及执行。它是受害者，不是凶手。假设二也出局。 三、真相：所有鸡蛋，放在一个会发烫的篮子里 那条温度告警指向了根子：我 NAS 上所有 Docker 数据，都单独放在一块廉价消费级 NVMe 固态上，没有任何冗余，而这块盘早上 7 点冲到了 67°C。 ...

起因 手上一个加密 U 盘，厂商只提供 Windows 客户端：插上后要先运行盘里的程序、输密码，加密区才会挂出来。而我的电脑是 Apple Silicon 的 Mac。 思路很直接：用 UTM 起一台 x86 Windows 虚拟机，把 U 盘直通进去，在里面解锁，再把文件传回 Mac。技术上每一块都是成熟的，我以为一个小时能搞定。 结果花了两天。这篇把坑记下来——不写代码，只讲现象、原因和实测数字。 一、先认清天花板：为什么注定慢 这件事的前提很残酷：Apple Silicon 是 ARM，而这个客户端只能跑在 x86 Windows 上。 在 M 系列芯片上跑 x86 系统，所有虚拟化方案都帮不上忙——Parallels、VMware 在 Apple Silicon 上根本不支持 x86 Windows，它们只能跑 ARM 版。UTM 是少数还提供 x86 模拟的，代价是走 QEMU 的 TCG：把每一条 x86 指令翻译成 ARM 指令再执行，没有任何硬件加速。 实测 CPU 全程顶在 100%，而且只能用一个核。 单核不是偷懒，是正确性 我一度想加核心数提速，查下来这条路走不通：x86 是强内存序（TSO），ARM 是弱内存序。在 ARM 上模拟多核 x86，必须在几乎每次内存访问处插入屏障指令，不但更慢，而且 QEMU 的多线程 TCG 对 x86-on-ARM 支持并不完善。 这不是理论担忧——我前一天就栽过：多核配置下虚拟机输入卡死、Windows 安装直接损坏，改回单核才救回来。10 个核在这里帮不上忙，不是没给它用，是这种模拟方式无法安全并行。 ...