设备为群晖 SA6400，运行 DSM 7.3，6 块内置 SATA WD Ultrastar HC550 组成 RAID 5。存储空间管理员中只能看到硬盘状态“良好”，未显示温度，因此通过 SSH 核实硬盘实际温度。 通过 SSH 读取温度 在 DSM 的“控制面板 → 终端机和 SNMP”启用 SSH 后，登录 NAS，执行： sudo synodisk --read_temp /dev/sata1 返回示例： disk /dev/sata1 temp is 41 其中数字单位为摄氏度。/dev/sata1 到 /dev/sata6 分别对应六块物理 SATA 硬盘。 可一次查看全部物理盘： for i in {1..6}; do sudo synodisk --read_temp /dev/sata$i done 注意：不要对 /dev/sata1p1、/dev/sata1p2 等分区逐一判断；它们只是同一物理盘上的系统、交换或数据分区，温度与对应物理盘相同。 本次温度结果 硬盘 温度 /dev/sata1 41°C /dev/sata2 39°C /dev/sata3 38°C /dev/sata4 39°C /dev/sata5 41°C /dev/sata6 38°C 六块盘温度在 38–41°C 之间，最大差值仅 3°C。对 7200 RPM 的企业级 HC550 而言，这个温度区间正常，且说明 SA6400 的盘位风道和散热较均匀。 ...

今天早上，一次普通的打车经历，让我心里久久不能平静。 从家到东站，一段很普通的路程。 平时打车也就二十多块钱，今天却显示接近28元。 我有些疑惑，于是联系高德客服询问： 为什么同样的路线，价格突然高了这么多？ 客服告诉我： 本次行程费用在合理范围内。 随后解释，高德作为聚合平台，会同时呼叫多个服务商和车型，价格会根据实时情况有所变化。 最后，平台给了一次所谓的“特殊处理”，减免了一部分费用。 事情本身其实不大。 十几块钱，也不值得斤斤计较。 但是，这件事情让我想到的，却不是这十几块钱。 而是那个司机。 一个刚入行一个月的网约车司机 后来我了解到，这个司机才跑了一个月。 一个月时间，已经完成了619单。 这个数字让我有些震撼。 619单意味着什么？ 意味着每天都在路上。 意味着长时间坐在车里等待订单。 意味着面对各种乘客、各种天气、各种不确定性。 他说自己现在还没有办理完整的网约车相关证件。 按照现在的要求，需要办理车辆营运相关手续，还需要考驾驶员资格证，包括考试、面试、服务规范培训等等。 整个流程下来，需要600多元。 他说： 以前没有这些要求，后来才开始有。今年7月份以后，不办理，就不能正常接单。 我听完之后，突然想到了一本书。 《骆驼祥子》。 祥子的悲剧，真的只是时代不同吗？ 祥子生活在旧社会。 他最大的愿望是什么？ 不是成为富豪。 不是拥有权力。 只是拥有一辆属于自己的车。 他年轻、健壮、勤劳。 他相信： 只要自己努力，就能改变命运。 于是他拼命拉车。 省吃俭用。 一点一点攒钱。 因为他相信，未来会越来越好。 可是现实一次次击碎他的希望。 车被抢。 积蓄被骗。 生活打击接踵而来。 最后，那个曾经有梦想、有尊严、有目标的青年，变成了一个麻木的“车油子”。 很多人说： 这是旧社会造成的悲剧。 当然没错。 时代背景不同。 社会环境不同。 但是，我觉得《骆驼祥子》真正想表达的，并不仅仅是贫穷。 而是： 当一个人长期看不到努力的意义时，他会慢慢失去奋斗的动力。 今天的年轻人为什么开始“躺平”？ 有人说： 现在年轻人吃不了苦。 我觉得未必。 很多人并不是不愿意努力。 他们也曾经相信： 读书可以改变命运。 努力工作可以获得提升。 认真生活可以换来更好的未来。 可是，当一个人不断遇到这样的事情： 收入增长越来越困难。 生活成本越来越高。 规则越来越复杂。 付出和回报越来越不匹配。 他开始怀疑： “我的努力，到底有没有意义？” ...

文中所有 IP、序列号、密钥均已脱敏。 上一篇写了「掉盘疑案，真凶是电源」，那时候刚定位到病根。这篇是后续：换电源、装系统、抢救数据、恢复服务，直到整套跑起来。 跨度不小，中间我下错过三次结论。技术细节值钱，但那三次错更值钱。 一、换电源之后：先验证，再动数据 新电源装上，第一件事不是急着拷数据，而是压力测试。 理由很简单：硬件不稳的时候搬 13T，等于拿数据赌运气。 # 6 盘并发满速只读，每盘 30GB for d in sata1 sata2 sata3 sata4 sata5 sata6; do ( dd if=/dev/$d of=/dev/null bs=1M count=30000 iflag=direct & ) done wait 前后对比 dmesg： dmesg | grep -icE "hard reset|link down|COMRESET|unplugged|failed command|ATA bus error" 结果：186GB 并发读取，六块盘全部 260-273MB/s 满速，dmesg 零新增错误。 对比换电源前——同样 6 块盘，一加压力就 hard reset、COMRESET failed、device unplugged 刷屏。至此供电问题确认解决。 这套压测方法可以复用：全程只读，不写入任何数据，安全。判断标准不是"能不能跑完"，而是"dmesg 有没有新增链路错误"。 二、抢救数据：只读挂载是硬保证 飞牛的存储结构和群晖几乎同构（mdadm + LVM + btrfs 三层），所以数据盘插到 DSM 上能手动读出来。 关键是全程只读： # 组装阵列，--readonly 从内核层面禁止写入 mdadm --assemble --readonly /dev/md20 /dev/sata5p1 # DSM 的 LVM 有设备过滤器，必须用 --config 覆盖才扫得到外来卷 CFG="devices{filter=[\"a|/dev/md20|\",\"r|.*|\"]}" pvs --config "$CFG" vgchange -ay --config "$CFG" # 只读挂载 mount -t btrfs -o ro /dev/mapper/trim_xxxx-0 /mnt/fnos 挂上之后 df 显示 14T/已用 13T，目录结构完整。即便中途出过 I/O 错误，因为全程只读，源盘一个字节都没被动过。 ...

那天晚上，我在房间里捣鼓电脑，一个小毛病，鼓捣了半天。她站在门口，跟我说着话。我眼睛盯着屏幕，“嗯"“哦"了两声，后来干脆没了声音。 我不知道她在门口站了多久。等我回过神，她已经哭了。 她说：你对我，已经很久没有回应了。我说什么，你都没啥反应。你更像一个合伙人——一个能一起把日子里的问题解决掉的伙伴。 我当时是愣住的。脑子里第一反应，是替自己辩护：我怎么会不爱你？你生病那次，我请假连轴转，白天黑夜守着你，一有情况立刻带你往医院跑。这些年，我连一次动摇的念头都摁得死死的。我没做错什么。 可这些话，我一句都没说出口。因为就在愣住的那几秒里，我明白了一件很凉的事： 我想举的所有证据，证明的，恰恰是她说的那句话。 合伙人是什么？合伙人就是——只在出了事、有问题要解决的时候，才出现的那个人。 我总记得自己连轴转陪她去医院的那一次，把它当成我深情的铁证。可我忘了，这大半年，家里装修、老人看病、一堆没完没了的琐事，几乎全是她一个人忙前忙后扛下来的。那阵子我总说自己没空，家里的事根本无暇顾及。 说白了：我记住的，是我的高光时刻；她记住的，是我不在的每一天。 我一直以为，随叫随到就是深情。原来那只是合伙人的本分——而这半年，连合伙人的本分，都是她一个人在尽。 我们是怎么走到这一步的？没有争吵，没有背叛，甚至找不到一个可以指着说"就是从这天起"的节点。 我喜欢捣鼓数码，一个小玩意能研究一晚上；她喜欢追剧，一集接一集。一开始还会凑过去陪对方看两眼，后来发现说不到一块儿，就各看各的屏幕。客厅里坐着两个人，两束光，谁也不打扰谁。 麻木从来不是哪天突然发生的。它是温水，一度一度慢慢降下来。等你伸手一试、发现凉透的时候，早过了能察觉的那个点。 都说七年之痒。大家默认，痒，是想要新鲜感，是起了别的冲动。可我越想越觉得，冲动这东西不值得高估——一时的激情，退潮之后，剩下的还是一地鸡毛。 我甚至不觉得大多数人是"痒"了。痒，好歹说明你还有知觉，还在难受。更多的人，其实是麻木了。是那句我们都讲过的：都老夫老妻了，还要什么新鲜感。 我们把这句话当成成熟，当成安稳。可它其实很不负责任。它和"我又没出轨”，是同一种东西的两种说法——都在拿一条底线，给自己的麻木，发一张通行证。 一个丈夫，不是没出轨就算好丈夫。一个对妻子的呼唤、常年没有回应的人，也很难算是个好人。 而最难堪的是：我心里，其实是有她的。我是爱她的。 可这有什么用呢？我心里的东西，她收不到。她能收到的，只有我表现出来的。而我表现出来的，全是合伙人那一套——沉默、高效、就事论事。 没有说出口的爱，和没有，对她来说，是一模一样的。 我大概是把"我爱你"这三个字，也当成了一件"没有问题需要解决、所以不必启动"的事。省着省着，就忘了它本来是要天天用的。 今天，我走过去，跟她说了一句。 我说：媳妇儿，这段时间，辛苦你了。我爱你。 就这么一句，说得还有点别扭。它解决不了什么，也补不回那些各看各屏幕的夜晚、那些她一个人扛下来的日子。我更没底气保证，从明天起我就成了一个"有回应"的人。 但我想，回应也许就是从这儿开始的——不是等她再哭一次，不是等下一场需要我连轴转的危机，而是在一个再普通不过的、什么事都没有的下午，我主动转过头，看着她，说一句本该早就说的话。 七年之痒，痒的其实不是身体。是你有多久，没有好好地，回应过身边这个人了。

文中所有 IP、序列号均已脱敏，思路和命令不受影响。 起因：不想把数据交给不信任的系统 我的主力 NAS 之前跑的是飞牛（fnOS）。用下来功能没得挑，但有个心结始终解不开——它是国产闭源系统，数据主权这种事，等厂商真做了什么再想撤就晚了。所以决定迁回黑群晖（Xpenology），装完固定版本、以后也不升级了。反正我所有服务都在 Docker 里，迁移主要是存储和数据搬家的事。 结果这趟「简单的搬家」，在硬件上给我上了一课。 一个意外的好消息：存储格式其实兼容 动手前我最怕的是存储格式不兼容——以为飞牛是裸 btrfs，群晖认不出会强制格式化。上机一看 lsblk，发现自己想错了： sda1 → linux_raid_member → md → LVM2_member → btrfs → /volX 飞牛的存储结构和群晖几乎同构：mdadm（单盘 RAID1）+ LVM + btrfs 三层，md superblock 也是 1.2 版本。这意味着数据盘插到群晖上，理论上能用命令行手动挂载读出来，不必先搬走再搬回。 于是方案定了： 先备份不可再生的东西（服务配置、密码库、种子文件） 物理拔掉数据盘，用空盘装 DSM、建存储池 插回数据盘，命令行只读挂载，把数据灌进新池 第 2 步的拔盘是铁律——群晖装机时会在它能看到的每一块盘上划系统分区，数据盘不隔离就开装，13T 直接报废。 备份：几分钟的事，别省 不可再生的数据几乎全在配置盘上，才几个 G。用 tar 打包整个 Docker 目录，再对几个 sqlite 数据库做在线一致性快照（不用停容器）： import sqlite3 s = sqlite3.connect(f"file:{src}?mode=ro", uri=True) d = sqlite3.connect(dst) s.backup(d) # 一致性快照，避免热备份拿到撕裂的中间态 密码库、索引器配置、辅种记录逐个存好，双份放在 NAS 和电脑上，全部校验通过。这一步零风险、完全可逆，是整个迁移里唯一不该图省事的环节。 诡异登场：怎么数着数着盘就少了 麻烦从这里开始。我这台是 6 块 16T + 2 块 SSD。现象是这样的： ...

本文所有 IP、UUID、tailnet 域名均已脱敏，思路和命令不受影响。 症状 ChatGPT 网页能打开、能登录，但只要开始对话就出问题： 回答流式输出到一半卡住 反复弹「正在重新连接」 「正在思考」转很久才出字 代理是通的——别的网站都正常。这种半通不通的状态最难查，因为它同时排除了「完全没代理」和「代理挂了」两种最简单的解释。 先说结论 系统的第一顺位 DNS 是 Tailscale 的 MagicDNS（100.100.100.100），而 MagicDNS 自己没有配上游解析器，于是把非 tailnet 域名的查询转手交给了运营商 DNS——那正是投毒最严重的地方。 关键的一行，出自 tailscale dns status： Resolvers (in preference order): (no resolvers configured, system default will be used) 结果就是： 域名 解析到 归属 chatgpt.com 108.160.163.116 Dropbox api.openai.com 128.242.240.221 Verizon ab.chatgpt.com 162.125.32.12 Dropbox 而且 chatgpt.com 每查一次返回的假 IP 都不一样，前后测到过 Facebook、Dropbox、还有几个查不到归属的——随机投毒的典型特征。 ab.chatgpt.com 是 ChatGPT 的实时配置和流式通道之一。它被指到 Dropbox 的 IP，「正在重新连接」就是这么来的。 为什么是「半通不通」 因为机器上同时存在两套 DNS，而它们的干净程度完全相反： $ scutil --dns | grep 'nameserver\[0\]' nameserver[0] : 100.100.100.100 ← Tailscale MagicDNS（被污染） nameserver[0] : 198.18.0.2 ← Shadowrocket TUN DNS（干净） 198.18.0.2 是代理软件自己的 DNS，它返回的是 fake-IP，域名交给远端节点解析，完全不受投毒影响。但它排在第二顺位，轮不到它。 ...

本文所有 IP、域名均已脱敏。这不是一篇「我解决了一个难题」的爽文,而是一篇反面教材——记录一个排障者如何用一连串"看起来合理"的推断,把一个重启就能解决的问题,搞成了持续几小时的连环事故。 症状 那天在改自己的 PT 工具,改完要 scp 到 NAS 部署。忽然: $ ssh root@100.x.x.x Connection closed by 100.x.x.x port 22 同时: ping NAS 通,0.3ms nc -z 探测 22 端口 通(TCP 能握手) 但任何 TCP 连接(SSH、HTTP)都在精确 5 秒后被切断 而走 Cloudflare 隧道的公网域名访问 NAS 上的服务,一切正常 一个"网络通、端口开、但连接全废"的诡异局面。下面是我依次给出的五个结论,以及每一个错在哪。 误判一:「下载器把我的 IP 封了」 排查中确实发现 qBittorrent 返回了: 身份认证失败次数过多,您的 IP 地址已被封禁。 这条是真的,而且原因也确实是我的锅——我的程序没做连接复用,每推一个种子就重新登录一次,几千次错误登录触发了防爆破。 但它和 SSH 连不上没有因果关系。 我却把它当成了"整台机器出问题"的第一块拼图,开始沿着"NAS 出事了"这条路往下走。 教训:找到一个真问题 ≠ 找到了这个问题的原因。要问自己:它能解释我看到的全部症状吗? 显然不能——qb 封禁解释不了 SSH。 误判二:「sshd 挂了」 ssh -vv 显示断在: debug1: Connection established. kex_exchange_identification: Connection closed by remote host 连密钥交换都没开始就被掐。我据此断定:sshd 进程虽然"开关是开的",但实际没在服务。 ...

数据口径说明：本文GDP、财政数据主要来自各市历年《国民经济和社会发展统计公报》及政府工作报告；“税收收入"如无特别说明，指地方一般公共预算收入中的税收部分（不含上划中央的增值税、所得税分成部分）。写作时间：2026年7月。 一、先摆事实：宜昌的账面成绩单确实漂亮 2025年，宜昌GDP达到 6464.42亿元，增长6.1%；常住人口390.06万，人均GDP 16.52万元——这个数字什么概念？高于全省平均、湖北市州第一（超过武汉），放在中部六省80多个地级市里也是第一，甚至超过不少东部明星城市。 近十年的增长曲线更是陡峭： 年份 GDP（亿元） 备注 2015 3384.8 2017 ~3857 化工整治+挤水分，增速一度掉到2.4% 2020 4261.3 疫情 2021 5022.7 一年净增761亿，名义增速约17.9% 2022 5502.7 名义增速约9.6% 2024 6191.1 2025 6464.4 2015年到2025年，GDP从3385亿涨到6464亿，名义增长约91%，接近翻倍。 那么问题来了：这91%的增长里，有多少变成了政府口袋里的税、居民口袋里的钱、银行账户上的存款？ 二、第一把尺子：税收——GDP翻倍，税收原地踏步 财政数据是最难注水的。GDP是"算"出来的，税是真金白银"收"上来的。 宜昌地方税收收入的十年轨迹： 年份 地方税收收入（亿元） 同期GDP（亿元） 2015 200.0 3384.8 2016 176.7（-11.7%） ~3709 2017 163.2（-7.7%） ~3857 2024 220.9 6191.1 2025 236.1 6464.4 十年时间，GDP增长91%，地方税收只增长18%。 即便考虑2016年营改增、后续大规模减税降费和留抵退税（这是全国性因素，所有城市都在承受），这个剪刀差也大得刺眼。 换算成"税收/GDP"比值： 2015年：200 ÷ 3385 ≈ 5.9% 2025年：236 ÷ 6464 ≈ 3.7% 也就是说，2015年每100元GDP能给宜昌地方财政贡献5.9元税收，2025年只剩3.7元。同样一块钱的GDP，“成色"降了近四成。要么是当年的GDP更实，要么是现在的GDP更虚，要么是产业结构变得越来越"不产税”——三者至少占其一，很可能三者皆有。 三、第二把尺子：横向对比——和谁比，结论完全不同 单看一个城市容易失真，拉同体量城市对比（2024年数据）： ...

买了台 VPS，装上 3x-ui 面板，建了个 VLESS + Reality 节点，导入客户端——连不上。 这大概是所有自建代理的人都会遇到的场景。麻烦的地方在于：Reality 出问题时往往一声不吭，客户端就是转圈、超时，或者「连上了但打不开网页」，日志里也常常什么都看不到。到底是节点参数错了、面板配错了、还是核心有 bug？ 这篇文章记录我把一个「怎么都连不上」的 Reality 节点修好的完整过程。最后定位到三个独立的坑叠在一起，任何一个都能让节点报废。比起结论，我更想分享的是中间那套二分定位的排查方法——它能让你不靠猜，一步步把问题锁死。 文中所有 IP、UUID、密钥均为占位符，请替换成你自己的。 一、现象 面板能打开，节点看起来建好了； 客户端导入节点，参数肉眼看都对； 开启代理后：能「连上」（延迟测试有数值），但网页打不开，浏览器报 ERR_TUNNEL_CONNECTION_FAILED。 「能连上但打不开」是最迷惑人的现象——它让你以为握手成功了，其实很可能根本没成。 二、排查的核心思路：不要猜，做二分 Reality 链路从客户端到目标网站，中间有一长串环节： 客户端参数 → TCP 到服务器 → Reality 握手 → VLESS 鉴权 → 服务端出网 → 目标网站 排障的关键，是逐段验证，把「好的部分」和「坏的部分」一刀切开。我用的判据工具很简单： 在任意一台机器上跑一个 xray 客户端（brew install xray 或官方二进制都行），配好 socks 入站指向节点，然后： curl --socks5-hostname 127.0.0.1:10808 https://api.ipify.org 返回 服务器的 IP → 这一段链路完全通； 返回 空 → 卡在 Reality/鉴权，去看服务端 debug 日志； 返回 本机 IP → 根本没走代理。 用官方 xray 命令行客户端、而不是直接用 GUI 客户端（Shadowrocket 等）来测，是因为命令行客户端参数透明、日志详细、可控，能把「参数问题」和「GUI 客户端自身问题」分开。这一点后面会救命。 ...