陈茂春的博客

当你爆发过敏性鼻炎时，这就是你体内发生的故事

Mon, 25 May 2026 09:34:13 +0800

今天，我们来聊一种折磨全球7亿人的疾病——过敏性鼻炎。

花粉

故事从一粒花粉说起。

这粒花粉直径30微米，闯入了你的鼻孔。

入侵免疫系统的第一防线——黏膜。

本来，皮肤才是第一防线上的主角，它属于物理防御，花粉根本不可能穿透皮肤细胞。

但是，人体有很多地方并不适合长皮肤，比如口腔、鼻腔、咽喉和其他有孔的地方。

于是，这些地方，身体就用黏膜来代替皮肤。

黏膜属于魔法防御，这里面有大量的免疫细胞和无人驾驶的杀伤性蛋白在巡逻。

鼻孔这个地方比较特殊，它和别的孔洞不一样，7x24小时都在工作，就像一个火车站，里面永远是挤满了进进出出的各种人员。

谁是小偷？谁是黑帮？谁是通缉犯？谁是地下党？

显然，这里的警力非常多，有基层的民警，有巡逻的特警，有无人机，还有便衣特工、谍报人员等等等等。

另外，这里还进化出来一套整个生物界都绝无仅有的安保黑科技——鼻毛。

现在，这粒花粉在鼻毛森林里穿行，如果它撞上鼻毛，鼻毛上的黏膜会死死的困住它，然后将会由无人机将它击毙、分解，再上报给巨噬细胞。

但如果，它穿过了绒毛森林，到达了鼻腔，等待它的又有两个命运。

第一，迫降在鼻黏膜上，免疫大军将来调查并处理它。

第二，迫降后借助你再次呼吸的动力，立刻起飞，强行冲向气管和肺部的方向，袭击身体。

幸好，鼻腔设计的非常的精妙，大于10微米的颗粒几乎不可能通过，所以，这粒30微米的花粉，基本可以肯定会被拦截下来。

但如果，它是一个小于10微米，甚至小于2.5微米的颗粒，那它就有可能闯过鼻腔，进入肺部，这样的话，就是另外一个PM2.5的故事了。

现在，花粉被鼻黏膜死死困住。

免疫大军还有5秒钟达到战场。

花粉VS免疫军团

首先赶到现场的是巨噬细胞，它比普通的免疫细胞大好几倍。

但当它看到这个30微米巨大花粉怪兽的时候，还是说了一句，艾玛，太大了，这绝对不是细菌，不该我管，自然杀伤，你去看看。

自然杀伤细胞很拽，头都不抬，直接怼回去，我只负责杀感染病毒的细胞和变异的癌细胞，这点儿破事儿不要找我。

白细胞也说，管我什么事儿，我又没接到上级的杀戮指令，我可不去。

大家又看看权限比较高的树突细胞，树突细胞正在喝茶，打了两个字——呵呵。

还有嗜酸性粒细胞，他也说，我只负责杀寄生虫啊，你们别看我，嗜碱性粒细胞，你去看看，你不是负责识别寄生虫的吗？

结果，嗜碱性粒细胞说，我是啦啦队啊，我连武器都没有，你们让我去送死啊。

这个时候，只有肥大细胞一个人默默地走了上去。

突然，它发现，原来特工早就过来了，B细胞也在这儿，正在研究这个花粉，B细胞说，不好，这是一个外来入侵者，你看，我把它的照片都提取出来了。

肥大细胞一拿到照片就慌了，因为，巨噬细胞、白细胞、树突细胞，它们都是手上有刀的爷，脾气都很暴躁，万一等会儿这个花粉开始像细菌、病毒一样复制自己，开始攻击身体，那它这个打更的小门卫是绝对要被拿去祭旗的。

所以，凭管大事儿小事儿，打更的门卫一定要夸大好几倍上报，只有这样，才能把锅从自己这里甩出去，反正严重性我早就说了，重不重视那就是你们的事儿了。

于是，肥大细胞就拿着花粉的照片在黏膜里仔细寻找，一旦发现第二个花粉，它就立刻开始报警。

释放大量的组织胺，组织胺就相当于让各种免疫细胞立即追杀入侵者的海捕文书，组织胺越多，白细胞、巨噬细胞这类基层细胞就得越拼命的完成KPI。

要是完不成？呵呵，一会儿淋巴特工们来了，也得拿它们祭旗。

所以，刚刚那些还高高挂起的免疫细胞们立刻投入战场，开始进行无差别杀戮。

于是，你开始感到鼻子有点痒，这其实是有几百上千个无辜的鼻腔细胞正在被白细胞误杀。

然后，肥大细胞又监测到一群花粉，它吓死了，立刻调高警报等级，这次，除了释放组织胺，还会释放——白细胞素。

这个白细胞素权限非常高可以让血管立即调集大量的组织液和白细胞赶到战场，甚至还可以进入神经中枢，直接调高体温，或者是跑遍全身，动员所有的免疫细胞准备杀敌。

这就是为什么有些人花粉过敏会出现发烧、浑身起疹子的真正原因。

但大多数人没这么严重，会开始打喷嚏，然后鼻塞，喷嚏是因为，神经系统以为这里发生了严重的外敌入侵，它正在拼命激发身体制造14级台风，用喷嚏把这些外敌排出去。

鼻塞是因为大量的组织液被调集过来，鼻腔已经进入了战斗状态，毛细血管全部膨胀，大量向前线运兵，肿胀的毛细血管占用了鼻腔里的空间，就导致了鼻塞。

接着，免疫细胞从鼻腔一直杀到眼睛那里，眼眶红肿了，眼泪和鼻涕也一直不停的流，这是身体在分泌体液，排出那些被无辜杀害的鼻腔细胞。

这一切，就是正在折磨着全球7亿人的疾病——过敏性鼻炎。

医学VS过敏

为什么到2021年，人类还无法彻底治愈鼻炎？

其实，看懂了上面这帮免疫细胞们的故事，你就应该理解医生了。

所谓的鼻炎，就是鼻黏膜发炎，发炎就是指免疫细胞在身体上攻击病原体的过程。

而过敏性鼻炎的战场上真的有病原体吗？

显然，花粉不会复制、不会攻击身体，不会在你身体内开出一朵花儿，它根本就不是病原体。

而这些免疫细胞其实是在攻击一个看不见的敌人——KPI（业务考核指标）。

这种为了KPI而奋斗的无力感，相信大家都懂……

所以，过敏，这种由KPI引发的疾病，根本就不是医生能管得了的。

只能靠你自己了。

怎么靠自己呢？

这里有一篇论文，我们不妨一起学习一下。

鼻炎解药·啪啪啪

这可是9月10日刚刚揭晓的搞笑诺贝尔奖成果。

一个来自英德两国的研究团队猜想，如果鼻塞是因为鼻腔毛细血管肿胀而导致的，那是否可以通过把血液调集到身体其他部位提供肿胀而缓解鼻腔压力呢？

于是，他们设计了这样一个实验。

找来了18对情侣，先检测它们的鼻腔阻力和气流量基线。

然后，请他们两两进入房间，在里面一定要达到——不生不灭的佛菩萨，一尘不染的大神——的那种境界。

具体方法，参考这期会员视频。

半个小时后18对情侣都表示，自己刚刚已经冲上了顶点，很是舒坦。

然后，研究团队开始测量，冲击顶点后30分钟，1小时，和3小时的鼻腔数据，记录为A组。

第二天，18对情侣被要求再来一次，但这次开始前，他们需要先往鼻腔里喷点缓解充血的药物。

结束以后，数据记录为B组。

对比A、B两组数据，研究团队得到了这样一个结论。

冲击顶点可以有效的缓解鼻塞，其效果和使用药物的效果不相上下，但持久性较差，只能保持3个小时，而药物可以保持更长的时间。

也就是说，你若想用这种方法来治疗鼻炎，那么请务必每三小时就来一次。

其实吧，按照这个研究的思路推理一下，我们不难发现，这里用来缓解鼻塞的原理，是通过身体其他部位的剧烈运动，把鼻腔的血液调走。

所以，事实上你去打个篮球、游个泳也会有类似的效果。

再回想一下，你去看医生，医生是不是也跟你说，鼻炎得加强体育锻炼，多运动，多接触户外空气？

但按照过敏的理论来看，医生说得有问题啊，过敏性鼻炎，不是因为接触了过敏原吗？

户外空气中，各种灰尘、冷空气、花粉、尾气，过敏原多得去了，难道要以毒攻毒？

过敏的本质

其实，过敏的本质和进化有关。

可能你听说过，糖尿病、痛风、三高，这些都是现代人近几十年饮食习惯突然变好而导致的富贵病。

过敏性鼻炎，也是类似的原理，仔细回想一下，30年前，你听说过几个人过敏鼻炎？

但根据2018年这项研究来看（《中国过敏学会过敏性鼻炎诊断与治疗指南》），过去6年时间内，中国新增1亿过敏性鼻炎的患者。

这背后的真正原因，和糖尿病一样，是因为环境突然改变，身体的进化还没有跟上环境改变的节奏。

人类的鼻子非常精妙，进化了几百万年，在野外使用了几十万年，它必须敏感。

但这种敏感却不是为空调房和城市所准备的。

它的敏感，是为了监测自然和乡土的气息，是在时刻准备着应对海风、丛林和草原上的突然情况。

所以，像原始人和古代人一样时不时的回归山林也是缓解过敏性鼻炎的有效方法。

虽然，野外有无数花粉和千奇百怪的过敏原，但你鼻腔里的肥大细胞，会在大自然的气息中，不再对花粉那么紧张。

这种自然疗法，你不妨把它理解为——逃离北上广，去他的KPI。

是不是突然觉得心情就不那么焦虑了？

恰好，焦虑也和过敏有关。

肥大细胞

肥大细胞就像一个有焦虑症的小白领，整天被KPI吊打，被大佬们霸凌，回家的地铁上还要被洗脑，主动去听点什么贩卖焦虑的成长课程。

所以，肥大细胞非常敏感，在工作上一点儿都不敢马虎，表面妆容精致，内心焦虑的要死。

你的状态是不是很像肥大细胞呢？

不用怀疑，你的细胞和你的情绪是一致的。

前面我们说过了，现代医学已经证实了，时不时的大笑。

就能激活自然杀伤细胞，自然杀伤是个every day party的公子哥。

公子哥一般都很傲娇，只要它开心，不用谈钱，它就喜欢杀个癌细胞，越杀越兴奋的那种，而一旦它不开心，多少钱都请不动它去好好杀白细胞。

我们经常听说，有些人不知道自己得了癌症，整天乐呵呵的，过了几年去复查，癌细胞都消失了。

这其实就是因为，他乐观的心情也激活了自然杀伤细胞，它正在体内高高兴兴的帮你追杀癌细胞呢。

而肥大细胞呢？

恰好是个焦虑的小白领。

不仅你的焦虑心情会让肥大细胞变得更加敏感，同时，肥大细胞被激活后释放的组织胺和其他化学成分，也会进一步让你更加抑郁，甚至患上抑郁症。

因为，肥大细胞虽然职位低，但它是免疫细胞里极少可以直接和神经系统沟通的角色。

所以，肥大细胞受心情的影响，和肥大细胞影响心情的能力，都比自然杀伤还要强很多，说不定，你看完这期节目，明天就把老板炒了，中秋就飞到海边去剧烈运动了，然后在月光下，你突然觉得神清气爽，那么，不妨站在你细胞的角度上，再仔细思考一下，你工作的意义，认真的听听身体怎么说。

不要觉得过敏是小事儿，它其实是你的细胞们已经被KPI虐到变态的前奏。

而一旦它们陷入抑郁和疯狂，你只会比它们更惨。

到底有多惨，大家不妨先做好心理准备，再去搜索一个叫肥大细胞增生症（cutaneous mastocytosis）的疾病，相信看过图片以后，你一定会回来留言，见鬼去吧KPI。

当然，上面跟大家分享的都是治疗鼻炎的祝由术，属于心理学方法，很玄乎。

那有没有什么直接点儿的生化方法呢？

激素VS鼻炎

回到前面花粉入侵的故事，我们会发现，所有的问题，都是从肥大细胞释放组织胺那一刻开始的。

我们不能杀死肥大细胞，但可以用药物控制组织胺啊。

于是，医生们发明了第一类治疗鼻炎的药物——抗组胺

肥大细胞释放的组织胺是这样一个把手向下的流星锤，血管细胞、神经细胞、免疫细胞等等各种细胞的表面，都有专门接受这个流星锤的插销，一旦组胺流星锤插入细胞销孔，那这个细胞就得立即开启免疫反应。

但是，人类可以合成一种叫做抗组胺的流星锤，原理很简单，只需要把组胺流星锤的把手从向下改成向上，组胺就变成了抗组胺。

抗组胺也会结合到细胞的组胺销孔上，但它们不是组胺，细胞不会开启免疫反应。

而当组胺在过来的时候，细胞上的销孔被抗组胺插上了，它们根本无法再给细胞下达免疫反应的指令，于是，抗组胺就失效了。

这种抗组胺类药物，虽然可以缓解过敏性鼻炎，但大家发现一个问题没有。

那就是，你通常是鼻塞了以后，才意识到鼻炎发作了，而这个时候再用抗组胺，虽然能扼制过敏进一步爆发，但是，已经造成的鼻塞无法逆转，战场上那些细胞的销孔已经被组胺插上了，抗组胺也是插不进去的。

这就尴尬了，我用药不就是为了让鼻子通气吗？

那有没有既能缓解鼻塞，还能扼制过敏的药物呢？

于是，医生们又发明了第二类药物——甾体激素。

甾体是一种四个环，三条链的无人机，长得就跟甾体一模一样。

这个甾体有什么用呢？

我们不妨这么理解，肥大细胞激活前线战场以后，神经系统是要监管战场的。

这个时候，甾体就像一批批800里加急文书，在皇宫和前线之间传递信息。

皇帝是你的神经系统，它靠甾体的数量来评判前线战事。

如果甾体少，它会认为战争还很胶着，还需要派更多军队去作战。

如果甾体多，它会认为，已经打赢了，可以收兵了。

于是，当你将医生开给你的糠酸莫米松喷进鼻孔的时候，其实是在喷射甾体，很快，你的神经系统就会发现。

前线来了很多甾体，看来战斗结束了，于是下达停战指令。

现在是不是明白为什么医生一定要叮嘱你，糠酸莫米松一天只能喷一次，千万别多喷，喷多了会形成药物依赖什么什么的。

其实，这是因为，甾体在欺骗你的神经系统，要是皇帝被骗习惯了，就会像袁世凯一样。

当年京城里有两版《顺天时报》，一版是街上卖的，上面写着，革命尚未结束

另一版专门给袁世凯看，上面写着，袁公称帝千古。

你看，精明如袁世凯，也架不住整天被大量甾体哄骗。

所以，千万听医生的，自己瞎用糠酸莫米松，你的神经系统就会变成下一个袁世凯。

鼻炎VS智商

传说，每一个天才都是重度鼻炎患者。

因为，上帝觉得他们太聪明了，但又不忍心收回他们，于是，让他们患上了鼻炎这种降低智商的疾病。

如果大家有过正在考试的时候，鼻炎突然发作的经历，相信一定会对这个传说会心一笑。

真的太形象了，凭管你如何专注，凭管你大脑如何超频，凭管你是否正在集体潜意识上疯狂下载数据。

鼻炎一来，简直就是拉闸限电。

大脑功率立刻下降，集体潜意识瞬间掉线，别说灵感了，就连解题、算数都变得很困难。

更何况，你还要照顾那一条即将落到考卷上的鼻涕……

比如，这份2020年的研究，43名过敏鼻炎的儿童（8-17岁），和26名不过敏的对照组，进行相同的记忆力和认识测试。

测试进行两次，分别安排在，花粉季和非花粉季。

结果发现，花粉季的时候，过敏组的记忆力和认识水平出现了明显的下降。

这是因为，花粉季过敏组儿童会患上鼻炎，这导致它们吸入氧气不充足，血氧浓度下降，无法支持大脑超频工作，也就导致了他们智力下降。

所以，中考、高考安排在6月，这是非常公平的，不是花粉季，大家的大脑都不限速。

这项研究还告诉我们，千万别觉得鼻炎是个小病，治不治没关系，没准儿哪天就好了。

事实上，儿童如果长期患有鼻炎，是会影响到智力发育的，而成年人的鼻炎，也会严重影响到他的创作灵感和工作效率。

关于鼻炎，还有一个有趣的研究。

狐臭VS鼻炎

可能在校住宿的学生党，经常会把自己鼻炎过敏，归结为某某某身上的狐臭。

其实，狐臭是不是过敏原，这个真的找不到相关研究证据。

但从进化上来说，狐臭不仅不是过敏原，反而很是一种鼻炎解药。

因为，这里有一张基因地图。

黄色是一种叫做ABCC11-T的基因突变，在第16号染色体上。

正是这个突变让人体失去了狐臭，突变的时间大约发生在2000代，也就是4~5万年前。

也就是说，如果你没有狐臭，那你肯定是4万多年前这个突变超人的后代。

从图中就可以发现，我们中国人，甚至整个东亚，都是拥有ABCC11-T这个突变。

事实也证明，97%的中国人没有狐臭，90%的西方人有狐臭，最严重的是非洲人，只有0.5%没有狐臭。

那狐臭究竟是什么呢？

首先，狐臭不是一种病，也不会传染，你没有狐臭那只是因为你的祖先在4万多年前变异了。

本来，人体的腋下、胯下、乳晕、外耳道这些地方，是有一种叫做大汗腺，或者顶浆腺的腺体。

一般的汗腺分泌出来的汗液都是盐水，不会有味道。

而大汗腺不一样，它分泌出来的汗水当中就有一些糖类、蛋白质、脂肪酸这类东西，再加上37℃的体温。

这就简直和细菌培养基一模一样了，狐臭，也就是皮肤里的细菌，分解大汗腺分泌物时所产生的酸味。

当然，有些人狐臭非常微弱，甚至微弱到闻起来像是一阵幽香，这就导致他并不知道自己有没有狐臭。

其实，判断狐臭还有一个方法，那就是看耳屎，如果是油耳屎，那证明你有狐臭基因（ABCC11），不管闻不闻得到，你其实都有狐臭。

而如果是干耳屎，则说明，你没有狐臭基因（ABCC11-T），不管你身上多么臭，那都是不是狐臭。

人类几百万年以来，都保留着狐臭基因，这证明，狐臭在野外生存中，一定有重要的意义，会是什么呢？

显然和气味有关。

而气味，在进化当中，其实是人与人沟通的一个重要信息，比如直到今天，我们都还会说——气味相投。

这其实不是一个比喻词，而是4万年前，我们祖先没有变异之前的写实词汇。

设想一下，一个有鼻炎的原始人，他在原始世界里，是不是就像盲人一样？

所以，狐臭与嗅觉的关系，就像皇帝和反贼的关系一样，为了准确的识别气味信息，你体内的嗅觉系统，一定会拼了命的抑制鼻炎系统。

而狐臭，恰好是可以激活你体内这种原始嗅觉本能的东西。

下次千万别说，你讨厌某某身上的味道，那股咖喱味儿让你鼻炎天天发作，其实，你讨厌的不是味道，而是人。

不信，你让女神送你点儿原味套装试试，还鼻炎呢，不存在的。

另外，关于ABCC11基因，还有一个冷知识，那就是为什么民间有一个说法，找老婆，最好找有点狐臭的。

这其实是因为，ABCC11基因主管腺体分泌，而奶水也是一种腺体分泌物。

有ABCC11基因的女性，她们的奶水会很旺盛，会有大量的母体免疫物质通过奶水输送给小宝宝，所以，狐臭也就意味着，婴儿能从母体获取更强的免疫力。

但我们的祖先突变了，失去了ABCC11基因，这就导致我们的母亲总是奶水不足，小宝宝也无法获得更强的母体免疫力。

好了，今天的故事就分享到这里，谢谢大家。

最后夫人说，所以，按照你的狐臭理论，去火车站睡一晚上，闻一下千万人的闻道也能治鼻炎？

（完结）

OpenWrt IPv6 设置方案

Wed, 15 Oct 2025 09:53:32 +0800

0. 前言

让你优雅的使用 OpenWrt 的 IPv6 功能。

本方案设置以 OpenWrt 主路由拨号环境设置。

0.1. 关于旁路由

不提供旁路由的任何设置方案
强烈建议使用主路由架构，抛弃错误的旁路由。旁路由爱好者请自己想办法，谁教你架设旁路由的你去找谁，不要提问。

具体原因见：关于旁路由的一些吐槽

0.2. 关于二级路由

二级路由的 IPv6 设置方法，网上教程很多，我自己没有这样的使用环境，所以也不提供任何设置方案，请自行百度。

0.3. 关于 IPv6 设置前提

现在三大运行商的家宽基本都提供 IPv6 地址，请确认光猫中已经开启 IPv6 功能（即 Internet 连接为 IPv4&IPv6）。
你的宽带能够获得 IPv6-PD 地址，才能适用本方案。
如果不能的话，暂时请寻求其他的解决方案。

1. OpenWrt/ImmortalWrt 固件 IPv6 设置方案

本方案仅仅提供 OpenWrt/ImmortalWrt 固件的详细设置步骤，对于 LEDE 固件暂不提供详细设置步骤。

请确保你已经将光猫设置为桥接模式，使用 OpenWrt 作为主路由进行拨号。

光猫改桥接请打光猫上的装维师傅电话进行修改。

1.1. Dnsmasq 设置

关闭 Dnsmasq 的“过滤 IPv6 AAAA 记录”功能。

如果不关闭此项，Dnsmasq 解析的地址中不会返回 IPv6 地址，也就无法访问 IPv6 网站。

1.2. WAN 口设置 IPv6 地址

WAN 口方法分为，自动创建和手动创建，请二选一即可。

自动创建

没什么特别的要求用自动创建就行。

不需要新建 WAN6，已有的 WAN6 接口要删除。
在 WAN 口的高级设置中，开启 IPv6 的选项，并勾选使用运行商通告的 DNS。
禁用IPv6 分配长度。
启用委托 IPv6 前缀(启用的话 lan 是没有 IPv6 地址的)。
IPv6 首选项不要填，填了会获取不到地址的。
按图设置。

在 WAN 接口的 DHCP 中检查设置，确保 DHCP > IPv6 设置已经关闭

保存并应用设置后，你的接口界面中应该会出现一个虚拟的 wan_6接口。注意此接口是无法编辑设置的。
确认红框中的 IPv6-PD 地址，获取到了这个地址才能进行下一步操作。

手动创建

禁用以下选项：

WAN > 高级设置 > 获取 IPv6 地址  
WAN > 高级设置 > IPv6 源路由
WAN > 高级设置 > 委托 IPv6 前缀
WAN > 高级设置 > IPv6 分配长度

在 OpenWrt > 网络 > 接口界面，新建一个接口，并命名为 WAN6

按照图中内容对 WAN6 接口进行配置

保存并应用配置后，检查 WAN6 接口是否取得了 IPv6-PD 地址。

如果你没有 PD 地址，说明你的 PD 地址被上一级路由占用了，或者干脆你的运行商没给。

如果是前者，不适用本方案。如果是后者，直接打你光猫上的电话联系运营商的装维人员（不要打 10000 号等电话，浪费时间），和运维师傅确认宽带是否能提供 IPv6-PD 地址，以及你的光猫桥接设置中是否选择了 IPv4&IPv6（有些装维人员会只设置 IPv4）。

1.3. LAN 口设置下发 IPv6 地址

完成 WAN 设置后，接着进行 LAN 设置。

“委托 IPv6 前缀”允许下级设备再划分子网，按需勾选。

接着设置 LAN 口的 IPv6 网络地址分配服务，让局域网设备可以取得 IPv6 地址。

需要说明的是，IPv6 地址由前缀和后缀组成，前缀由运营商下发，后缀有两种获取 IP 的方式：

1、SLAAC（无状态）：后缀由局域网设备自身生成。
所有类型的设备都支持该功能。
2、DHCPv6（有状态）：后缀由 OpenWrt 统一管理。
安卓设备以及其他的一些设备（如智能家居设备）不支持该功能。

没有特殊需求的话，建议使用 SLAAC 分配 IPv6 地址即可。SLAAC 和 DHCPv6 可以共存，也可以单独开启。

此处关闭 DHCPv6，启用 SLACC，并使用 eui64 参数来启用 EUI-64 网络地址分配方式，从而形成固定 IP。

这里参考了如下设置：immortalwrt/user-FAQ/如何优雅的使用IPV6？

在 LAN > 高级设置 > IPv6 后缀 中填入 eui64

EUI-64 可以让设备的后缀地址由 MAC 地址生成，因此可以生成唯一的后缀。

EUI-64 网络地址分配方式的技术解释可以看 ImmortalWrt 仓库的文档：immortalwrt/user-FAQ/关于eui64的一些说明

同时我们需要禁止 OpenWrt 通告 IPv6 地址的 DNS，因为设备只需要 OpenWrt 的 IPv4 DNS 地址即可实现 IPv6 解析。

强迫下游设备使用 OpenWrt 的 IPv4 地址（比如192.168.1.1）来解析包括 IPv6 域名在内的全部域名，防止 IPv6 DNS 抢答解析请求，不会影响设备正常访问 IPv6 域名，同时可以避免发生一些相关的问题。

如此设置之后，局域网支持 IPv6 的设备都将获得一个固定且唯一的 IPv6 地址，并且 IPv6 DNS 为空。

注意：一些设备和系统（Windows、iOS、Debian 等）出于隐私防护的考虑，会在已获取 SLAAC 地址的情况下，强制生成额外的临时 IPv6 地址用于对外访问。

例如：https://github.com/Aethersailor/Custom_OpenClash_Rules/issues/225

如果发现设备获取了多个 IPv6 地址，这是一种预期行为，不影响使用且无任何负面影响，设备由 SLAAC 获取的固定后缀 IPv6 地址仍然存在且可正常工作。

你可以理解为固定 IP 和随机 IP 同时存在。设备对外访问使用了随机的 IPv6地址来确保隐私，而你从外部访问设备仍然可以通过访问固定后缀 IPv6 地址来进行访问。

有特殊需求的用户，请自己搜索或者询问 AI 如何在对应系统下关闭此类隐私防护设置，建议保留该功能。

1.4. 测试

使用 Edge/Chrome 或者其他 Chromium 内核的浏览器，在关闭浏览器安全 DNS 功能的情况下，访问 IPv6 测试网站来验证设置是否正确：

请勿使用 Firefox 访问测试网站！ Firefox 默认 IPv4 优先，有可能无法通过测试。

https://testipv6.cn/

正常情况下，会取得全部通过的结果

至此，OpenWrt 的 IPv6 功能设置完毕。

1.5. 日常使用

如果想了解当前访问的网页，使用的是 IPv4 还是 IPv6 线路，可以使用浏览器插件IPvFoo，在 Chrome/Firefox 浏览器的插件商店中均有下载。

使用 Firefox 浏览器，请在 about:config 中将 network.dns.preferIPv6 的值设定为 true，否则浏览器不会使用 IPv6 访问目标网站。

2. Lean's LEDE 设置方案

手头所有设备目前均不再使用 Lean's LEDE 源码固件，单纯是因为个人更喜欢官方版和 ImmortalWrt，所以以后也不会有 LEDE 的设置方案。

请自行摸索相关设置，设置内容相似。

图片仅供参考

3. IPv6 如何正确设置“端口转发”

首先明确一点，你的下游设备取得的都是公网 IPv6 地址，因此此处实际上并不需要“端口转发”功能，只需要设置对应的防火墙放行规则，即可实现和 IPv4 的端口转发一样的使用效果。

局域网内设备取得了 IPv6 公网地址，但是你会发现虽然从公网可以 ping 通这些地址，但是并不能直接访问这些地址的端口。

原因在于 OpenWrt 的防火墙规则默认放行转发给下游设备的 IPv6 的 ICMP 数据包，但是并没有放行其他的数据包。这是一种安全的设定，可以避免下游设备在取得 IPv6 公网地址后不安全的暴露于公网环境中。

如果你需要从公网访问 OpenWrt 的下游设备的 IPv6 地址的特定端口（比如群晖的 5000 端口，或者 SSH 的 22 端口），则需要建立相应的防火墙通信规则，对特定地址和端口进行放行。

具体设置参考：immortalwrt/user-FAQ/IPV6如何正确配置端口转发？

注意填写地址部分，只需要填写设备的 IPv6 地址的后16位，也就是由 MAC 生成的部分。

这样防火墙规则会按照地址后缀去匹配设备，无需担心运营商下发的地址前缀变动。而地址后缀是根据 MAC 生成的固定后缀。

4. 关于本地的 IPv6 DNS

需要说明一点，能否解析 IPv6 的 AAAA 地址并不取决于服务器自身是否有 IPv6 地址。

比如当你的 OpenWrt 的上游 DNS 服务器提供 IPv6 域名解析时，你的 OpenWrt 的 Dnsmasq 就可以提供 IPv6 域名的解析服务，这和你通过 IPv4 还是 IPv6 去请求 Dnsmasq 解析是无关的，即便你使用路由器的 IPv4 地址去请求域名解析，一样可以取得 IPv6 结果。

也就是说，当 OpenWrt 作为你的 DNS 服务器时，只要你的局域网设备获得了 IPv6 地址并且可以正常访问 IPv6 网络，即使局域网设备只取得了 IPv4 的 DNS 地址（比如 192.168.1.1），仍然可以通过 IPv4 的 DNS（192.168.1.1）去解析获得 AAAA 记录从而正常访问 IPv6 网站。

在我实际使用的过程中，Win11 就会偶尔出现可以 ping 通 OpenWrt 的 IPv4 局域网地址（192.168.1.1）但是无法 ping 通 OpenWrt 的 IPv6 ULA 地址（fda6:xxxx:xxxx::1）的情况，此时只要取消“本地 IPv6 DNS 服务器”勾选，并在“RA 标记”中取消“其他配置”的勾选，即让 OpenWrt 不再向 Win11 通告 IPv6 DNS 地址，从而强迫系统以 IPv4 DNS（192.168.1.1）来解析 IPv6 网站的域名来正常进行访问。

有点拗口是不是，那么无脑按照图中内容设置即可。

一句话解释：
你可以直接使用 IPv4 DNS （比如路由本身的192.168.1.1）来取得 IPv6 解析结果，不需要去折腾 IPv6 相关的 DNS 设置，让 OpenWrt 不要向下游设备通告 IPv6 DNS 地址即可，可以避免很多问题

从Debian 12升级到Debian 13.完整教程

Sat, 04 Oct 2025 15:44:49 +0800

Debian 13 稳定版历经两年零两个月的打磨，于 8 月 9 日正式亮相，代号 “Trixie”。手边正有一台运行 Debian 12 的测试服务器，与生产环境的谨慎迥然不同，它的信条只有一句——有更新就马上升，第一时间畅享最新特性。

️ 准备工作

️ 除非你使用的是物理服务器，或者 KVM 架构的 VPS / 云主机（且没有使用奇怪定制或修改的内核），否则升级时更新内核有一定几率导致 Grub 加载失败，⚠️ 切记备份重要数据！
OpenVZ 6 和 LXC 架构的 VPS 无法升级，因为它们没有独立内核。
⚠️ 再强调一遍：一定要备份重要数据！
以下操作需要在 root 用户下完成，请使用 sudo -i 或 su root 切换到 root 用户进行操作

更新系统

apt update
apt upgrade -y
apt full-upgrade -y
apt autoclean
apt autoremove -y

如果内核更新了，可以重启后让其生效，也可以直接继续升级。

升级系统

1. 更新 APT 源

将 bookworm 替换为 trixie：

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.sources

如果没有对应文件会提示诸如 sed: can't read /etc/apt/sources.list.d/*.sources: No such file or directory 的错误，忽略即可。

修改后的 /etc/apt/sources.list 示例

deb https://deb.debian.org/debian trixie main contrib non-free non-free-firmware
deb https://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
deb https://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware

DEB822 格式（/etc/apt/sources.list.d/debian.sources 示例）

Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

从 Debian 12 容器版本及 Debian 13 起，APT 默认采用 DEB822 格式。
若采用该格式，可以删除 /etc/apt/sources.list，只保留 debian.sources。
国内服务器可将 deb.debian.org 与 security.debian.org 替换为：

mirrors.tuna.tsinghua.edu.cn

2. 再次更新系统

apt update
apt upgrade -y
apt full-upgrade -y

Debian 13 早期版本可能提示你是否自动转换为 DEB822 格式，可用：

apt modernize-sources

转换后需手动修复 backports 仓库的 GPG Key。

⚙️ 升级过程中的提示

软件更新确认 → 选择 Yes

是否自动重启服务 → 选择 Yes

配置文件更新 → 默认回车表示保留旧配置（常见于 OpenSSH 等）

退出 apt-listchanges → 按 q

某些软件更新 systemd 配置时，执行：

systemctl daemon-reload

清理无用文件

apt autoclean
apt autoremove -y

重启并验证

reboot

重启后验证版本：

cat /etc/debian_version
# 输出: 13.0

lsb_release -a
# Distributor ID:	Debian
# Description:	Debian GNU/Linux 13 (trixie)
# Release:	13
# Codename:	trixie

uname -a
# Linux upload 6.12.38+deb13-cloud-amd64 ...

✅ 此时你的系统已成功升级到 Debian 13 Trixie 及最新内核。

总结

从 Debian 12 升级到 Debian 13 的流程包括：

首先确认架构（KVM/物理机可升级，OpenVZ 6 和 LXC 不支持）并完整备份数据
以 root 身份更新当前系统至最新状态
修改 APT 源，将 “bookworm” 替换为 “trixie”，推荐使用 DEB822 格式并可切换国内镜像
再次执行更新与全面升级，按提示选择是否更新配置文件和重启服务
升级完成后清理无用软件包与依赖，最后重启系统，通过 cat /etc/debian_version、lsb_release -a 和 uname -a 验证版本信息即可确认已成功升级到 Debian 13 及最新内核。

OpenWRT IPv6防火墙规则：如何放行客户端地址及端口

Sat, 10 May 2025 14:09:46 +0800

? 配置方法

由于OpenWRT旁路由没有wan口，所以默认所有的流量都是通过lan区域进行本地交换，一般来说不用单独在旁路由上进行防火墙配置，只需要在唯一与外网进行连接的主路由进行配置即可。

同时，不建议关闭IPv6防火墙，尽管IPv6地址和端口扫描难度很大，但是依旧存在被扫风险，届时所有的局域网服务均可能暴露在外网，即便不会遭到攻击，运营商也会因为你在家庭宽带提供公共网络服务给你打电话，因为存在可访问的界面。

LUCI界面配置方式

打开OpenWRT路由器管理页面，进入网络 - 防火墙 - 通信规则 ，点击添加 来新增一条规则，在通信规则中所添加的规则在默认规则上方，所以不用担心于默认路由器防火墙规则冲突，不能生效，但需要注意与同页面的其他通信规则是否冲突，如果有，需要可以通过拖拽的方式，调整OpenWRT防火墙通信规则优先级。

名称：根据自己需要填写，建议填写具有明显标识的规则名称，例如Sunshine IPv6 这样。

协议：根据需要放行的协议进行选择，如果不确定可以选择TCP和UDP，基本涵盖大多数应用使用协议。

源区域：即流量入口所泽的防火墙区域，选择wan区域。

源地址：不选择。

源端口：不填写

出口区域：即流量出口所在的防火墙区域，选择lan区域。

目标地址：通过ip -6 neigh show 查看需要进行放行的客户端的Link-local IPv6 Address ，也就是本地IPv6地址，一般来说以fe80::开头。选择地址后，删除link-local ipv6地址的前缀部分，例如我的地址为fe80::65e8:ee2a:10b3:b2d5 ，那么删除后就是::65e8:ee2a:10b3:b2d5 ,然后在后面添加/::ffff:ffff:ffff:ffff ，意思是匹配所有后缀为::65e8:ee2a:10b3:b2d5 的本地IPv6地址，将完整地址::65e8:ee2a:10b3:b2d5/::ffff:ffff:ffff:ffff 填入目标地址中。这样无论运营商下发的IPv6前缀如何变动，我们通过固定的后缀即可进行客户端的匹配。

目标端口：即放行端口，建议使用哪个端口，就填写哪个端口，可以填写端口范围，例如80-443 这种。不填写则默认全部端口放行，存在很大安全隐患，不建议。

操作：接受。

高级设置中，我们仅需要对地址族进行修改及限制。

地址族限制：修改为IPv6。

其他无特殊需要不用填写和修改，进行保存即可。然后可以尝试通过外网进行本地服务访问，如果在OpenWRT的状态 - 防火墙的规则容器链 "forward_wan" 看到对应规则及计数，即表示放行成功。

NFT命令方式

新手小白不建议采用nft命令方式进行防火墙放行配置。这里仅供参考。

例如我们需要对刚刚的::65e8:ee2a:10b3:b2d5/::ffff:ffff:ffff:ffff 这个客户端进行80端口的放行，则在SSH登录OpenWRT系统后输入：

nft add rule ip6 fw4 forward ip6 daddr ::65e8:ee2a:10b3:b2d5/::ffff:ffff:ffff:ffff tcp dport 80 accept

即通过nft add rule添加规则，操作fw4表与forward链，匹配目标地址为::65e8:ee2a:10b3:b2d5/::ffff:ffff:ffff:ffff的目标地址及tcp 80端口，允许防火墙区域wan的流量进行转发。

如果需要添加udp协议的流量，则为：

nft add rule ip6 fw4 forward ip6 daddr ::65e8:ee2a:10b3:b2d5/::ffff:ffff:ffff:ffff udp dport 80 accept

? 其他

关于后缀匹配规则

理论上，::65e8:ee2a:10b3:b2d5/::ffff:ffff:ffff:ffff 可以简写为::/64:65e8:ee2a:10b3:b2d5 ，即都表示该IPv6地址的前64位为可变动，后64位为固定地址。不可简写为::65e8:ee2a:10b3:b2d5/0 ，因为/0表示整个IPv6地址空间,意味着没有任何掩码，所有128位地址的匹配都符合条件，实际上匹配整个IPv6地址范围（即"所有地址"）

关于固定后缀

在IPv6与旁路由共存：实现策略代理与原生地址的完美平衡 这篇文章中，我建议在主路由的lan口和wan_6口，旁路由的lan口和lan_6口的高级设置中，将IPv6后缀设置为EUI64，这样将客户端的IPv6地址生成与设备的MAC地址形成一对一的绑定，只要设备的MAC地址不变，那么设备的IPv6地址后缀也就不变，从而在防火墙配置、路由配置等操作中更为方便。

提升家庭网络稳定性：OpenWRT限制京东云连接数教程

Sat, 10 May 2025 13:59:11 +0800

连接数量对网速的影响

之前我并没有意识到连接数量对网络稳定性和网络速度存在影响，但是查阅部分资料后，发现活动连接数量过多

会影响网速的原因主要包括以下几个方面：

带宽消耗：每个连接都占用了网络带宽，活动连接数量增加时，带宽会被多个连接分摊，导致每个连接可用
的带宽减少，最终导致整体网速下降。
路由器/网络设备的处理能力：路由器和其他网络设备在处理大量连接时会增加工作负荷。如果设备的处理能
力有限，过多的连接会导致设备反应变慢，增加数据包的处理延迟，进而影响网速。
网络拥塞：过多的连接可能会导致网络拥塞，尤其是在家庭局域网中。网络拥塞会导致数据包丢失、重传等
问题，进一步降低实际的传输速度。
NAT表的限制：对于使用NAT（网络地址转换）的网络，每个连接需要在NAT表中建立一条记录。NAT表的
容量有限，当连接数过多时，NAT表可能会溢出或处理速度变慢，导致网络性能下降。
CPU和内存负载：如果你的设备（如计算机或服务器）处理大量的并发连接，CPU和内存负载会增加，可能
导致设备性能下降，进而影响网速。例如我的Asus Acrh17，在12000活动连接数时，内存占用超过70%，
此时局域网内其他设备明显可感觉到延迟。
运营商活动连接数量限制：大部分运营商会对每户入网的宽带进行活动连接数量限制，不同地区、不同运营商
甚至所属不同片区均不相同，当达到一定量的活动连接数量时，更多的连接会进行丢包处理，所以会直接影响
到使用者的体验。目前检索到的消息可以查看这里：

宽带连接数限制测试结果（来源）：上海电信：公网不限制，私网 8000，云宽带 2800 上海移动：私网 2500 上海联通：公网 6000，私网 1500 江苏移动：公网不限制，私网 2500 浙江移动：公网 6000，私网 2000 江苏联通：公网 6000，私网 3000 江苏电信：公网不限制，私网 6000

本地网络环境介绍

简单介绍一下我本地的网络环境：

在这个家庭网络的拓扑结构中：

光猫：桥接模式（中兴老款F450，已尝试修改了硬桥接，未使用软桥接方式，同时，未做光猫本身最大
连接数修改）
主路由：ASUS-ACRH17，系统为OpenWRT，开启Fullcone NAT。
旁路由（旁路网关）：X86虚拟机（Hyper-V虚拟化），系统为OpenWRT的衍生版本ImmortalWRT
(本篇中并不重要)。
网心云：X86版本（Hyper-V虚拟化）并配置静态地址，网关直接指向主路由，避免流量经过旁路。

配置文件限制方法

主路由目前使用的OpenWRT版本为24.10，在这个OpenWRT版本中已经使用nftable取代了iptables，所以

在网上找到的很多iptables无法使用或者会提示过老版本,配置后查看规则计数器数据为0，没有生效。同时

nftable在OpenWRT上并没有提供luci app插件以及对应的UI操作界面，所以就需要我们自行编写nftable规

则进行连接数的控制。

在另一方面，由于主路由器开启了Fullcone NAT模式，所以使得所有来自外部的连接请求都可以通过主路由访问

内网的网心云，且不再使用UPNP。这意味着，如果在 nftables 中通过ip fileter添加了针对网心云的INPUT和

OUTPUT限制规则，那这些规则就不能正确匹配外部流量，所以通过INPUT和OUTPUT规则进行过滤没有任何的

效果，这也是我在尝试之后，发现匹配规则数量为什么一直都是0的原因。

同时，使用 conntrack （conntrack需要安装，一般都没有预装）查看连接时，我发现连接信息已经包含NAT处

理后的外部IP地址和端口，而nftables规则要考虑对NAT后的地址和端口进行限制，那么目标就来到了 forward

链上。

首先确保OpenWRT已经安装了以下内核，如果缺少的话，在使用nftable时候会提示报错：“Error: Could

not process rule: No such file or directory”。

modprobe nft_chain_nat
modprobe nft_counter
modprobe nft_ct
modprobe nft_limit
modprobe nft_reject

可以通过如下命令进行安装：

opkg update
opkg install kmod-nft-core kmod-nft-nat kmod-nft-connlimit

下面编辑文件限制udp连接数，（京东云如果限制所有连接数，会导致与云平台失联，虽然跑的很欢，但是积分很低）。编辑/etc/nftables.d/10-custom-filter-chains.nft 文件，取消注释并修改 user_post_forward 链，像这样：

chain user_post_forward {
    type filter hook forward priority 1; policy accept;
    # 限制从 192.168.0.4 发出的 UDP 连接数
        ip protocol udp ip saddr 192.168.0.4 ct count over 5000 counter drop

        # 限制发往 192.168.0.4 的 UDP 连接数
        ip protocol udp ip daddr 192.168.0.4 ct count over 5000 counter drop
}

然后重启firewall/etc/init.d/firewall restart

/etc/init.d/firewall restart

通过nft list进行查看规则是否已经添加成功

nft -a list ruleset

chain FORMARD { # handle 1
    type filter hook input priority filter - 1; policy accept;
    ip saddr X.X.X.X ct count over 5000 counter packets 0 bytes 0 drop # handle 36
    ip daddr X.X.X.X ct count over 5000 counter packets 0 bytes 0 drop # handle 37
 }

则表示添加规则成功。

OpenWRT查看端口占用

查看单独端口占用情况及对应程序，例如8080为要进行查看的端口

netstat -tulnp | grep 8080

2.查看客户端IP地址端口占用情况

netstat -tulnp | grep <客户端IP>

最终，通过Grafana查看效果（需要单独配置）：

总结归纳

整体所需的软件包为：

kmod-nft-core（核心）
kmod-nft-nat（nat相关规则配置参数支持）
kmod-nft-connlimit（计数相关规则配置参数支持）
conntrack（查看连接，可选）

以上软件包均可通过OPKG进行直接安装。

目前配置完成之后（我配置的来源和目的地活动连接数量均为4000），主路由显示的活动连接数量大概在5000

左右浮动，至于为什么没有完全和规则匹配上，我的猜想可能是因为有一些长连接还没有释放的原因，后续会进

行持续观察。

限制活动连接数量之后，对网心云的跑量影响需要等待几天才能看到，之后我也会更新到这里。目前来看，在上

传带宽方面没有任何的变化，依旧可以跑满限制带宽，理论上延迟应该也可以降下来，但存在一个副作用，就是

丢包也会上涨，这部分会影响多少的收益暂时还不清楚，同时具体连接数限制的数值的设定，也需要持续的观察

才能确认最优配置。

同时上述规则中没有配置IPV6的相关nftable规则，因为目前我的环境和观察下，IPV6的量只占很少的一部分，

如果之后量起来了，对本地的网络环境已经有了体感的影响，我也会进行研究相关配置。

这篇文章也不仅仅能应用于网心云，当你需要对局域网内的任何客户端，或者说是局域网内任何IP进行活动连

接数量的限制时，都可以根据上面的内容进行操作，尤其是对于抖音、快手、爱奇艺这种活动连接请求大户。

ZB文件权限安全设置指南

Sat, 15 Jun 2024 08:51:00 +0800

为了防止ZBLOG被黑或是系统漏洞网站被攻破，可以将网站权限做如下设置，可以在宝塔面板的文件管理里操作。

A：需要保留w权限的目录及子目录及其下所有文件

zb_users/cache
zb_users/upload

B：需要删除w权限的有

zb_system及其子目录
zb_users下除了cache,upload的其它目录
根目录下的index.php,feed.php,search.php

C：解决不能ftp覆盖或不能安装主题，插件的问题：

1.如果要覆盖zb_system就在文件管理里给zb_system及子目录增加w权限

2.如果要安装新插件，zb_users下的plugin目录也要增加w权限

3.其它有需求目录也同样处理。

4.为了防止黑客种木马在网站里，覆盖完成后请尽快删除增加的w权限

D：开启宝塔的代码防篡改功能。

E：nginx的安全配置

location ~* /(zb_users/cache|zb_users/upload|zb_users/logs)(.*)\.php$ {
deny all;
return 404;
}
location ~ ^/(\.user.ini|\.htaccess|\.git|\.svn|\.project|LICENSE|README.md)
{
return 404;
}

深入浅出玩转绿联 UGOS (下)

Wed, 31 Jan 2024 13:29:44 +0800

什么是 Linuxserver ？

我们会发现教程教学和 Docker 页面里的“常用镜像”使用的镜像全都不是来自于官方，而是来自于一个叫做 linuxserver 的开发者，所以需要介绍一下 linuxserver.io 到底是何方神圣。

linuxserver 由一群志愿者组成，致力于为开源软件构建改良的 docker 镜像，并且在官方镜像的基础上提供以下特性：

添加统一的 Ubuntu 系统底层，定期更新
跟随上游版本发布 CI 定期更新
增加 User Mapping 功能（ PGID 、PUID ）
S6 Overlay支持
将所有软件的用户配置文件解耦并统一管理
linuxserver 维护的所有软件配置文件都在/config 文件夹下，可以保证只要/config 不变，镜像版本无痛更新
友好的 fork 支持

配置文件解耦这一点很重要，每个 linuxserver.io 的镜像你只需要把他们的/config 映射到本地永久化储存，镜像就能够随意更新不受影响。

市面上非常多热门的“增强版”Docker 镜像都是基于 linuxserver.io 开发的

BT 下载器

绿联云套件已经内置了“离线下载”和“迅雷”APP 。这个“离线下载”实际上就是 Aria2 的封包，屏蔽了所有的参数设置；同时我们也知道吸血鬼迅雷是个什么东西，走在路上都要捏着鼻子避开。因此，一个正常的具有互联网精神的网民都应当会选择自建 docker 来完成远程下载。2023 年的 Linux 下载器不外乎就 2 个，qBittorrent 负责 BT ，Aria2 负责直链。

无它，因为在 BT 这方面 qBittorrent 实在是强太多。

部署 BT 下载器的时候一定要注意一件事情，把容器放在 Bridge 里面会导致网络严重受限，一切涉及到 BT 下载的容器请部署在 Host 网络。绿联官方的教程就犯了这个错误。

Aria2

很多人在部署 aria2c 的 docker 镜像的时候都会去优先寻找国人优化的“增强版”，我也一样，因此有个注意事项：

热度和下载量很高的p3terx/aria2-pro在绿联系统上有兼容性问题，会一直自动结束，无法使用

建议使用superng6/aria2代替。

同时，因为系统内置了 aria2c ，所以 6800 端口被占用，使用的时候需要更改成别的端口。

qBittorrent

qb 增强版我个人使用的是superng6/qbittorrentee，基于 linuxserver 镜像，并提供了各种喜闻乐见的优化，详情可以通过Github repo了解。

需要注意的是，网络模式设置成 Host 后，创建容器时的“端口设置”条目是无效的，程序的监听地址仅由环境变量中的WEBUIPORT指定。

如果你按照官方的**教程设置PGID和PUID为 0 的话，所有下载的文件 owner 会是 root ，默认权限 755 ，则通过 SMB 访问时不可写。

实战当中，我推荐将 QB 的容器用户指定为你在“网络服务”中创建的账户，通过 Linux 基础命令可以查询 UID 和 GID：

id <user>

比如我的账户叫做 nas ，查询得知 UID 和 GID 均为24****0000：

则创建容器时，在环境变量中指定他们为查询到的 ID：

在superng6/qbittorrentee镜像中，指定 UMASK 的环境变量名为UMASK_SET，而在 linuxserver.io 官方镜像中（应该）是UMASK。设置为 000 使得所有用户都能够读写，UMASK 的定义参见Wiki，反正绿联的文件权限管理哲学就是全盘 777 ，已经很危险了，所以不用害怕安全问题。

这至少能够保证挂载的 SMB 能够正常读写，其他成员通过套件访问时都会被 UGOS 自动重置成 root777 。

至于 QB 的内部设置，增强版基本已经做到开箱即用，没有什么注意事项，qb 本身的更多设置优化可以参考网上大量的文章。

存储空间映射则看个人喜好，我自己会喜欢为每个子文件夹单独创建一个映射，保持空间侵入最小化，而不是直接映射一个根文件夹让 QB 在内部自由访问，二者皆可。

强烈推荐增加一条 SSD 用来单独存放 config 和临时文件，这样可以降低机械硬盘负载，增加休眠几率，理论上延长写寿命。
在 QB 设置中，保存未完成的 torrent 到 SSD
Jellyfin 的媒体库很庞大时，Metadata 和 Cache 容量可能高达数十 GB ，放在 SSD 可以大幅加快加载速度，减少机械硬盘的小文件读

公网安全保护指南

在《深入解析》中我们已经分析过，UGOS 的 Nginx 把所有套件的端口都聚合到 9999 反向代理，但是没有做任何的手段去阻止端口对外暴露，所有套件的端口依旧监听在 0.0.0.0 ，这是一个非常大的安全隐患。我们可以简单在公网资产嗅探引擎简单搜索一下“绿联”或者“绿联私有云”，可以得到 2023 年光是中国大陆内就有约 5000 多台绿联 NAS 暴露在公网上，并且随便选个 IP 蒙常用端口都能进得去：

公网的高阶防护，端口隐藏之类可以通过 Docker lucky 来完成，但是在这里我不打算教这个东西，因为我也没部署。公网和论坛里有不少关于这个的教程都可以参考。

既然我们部署在大内网，那么优先的手段是利用大内网的优势，即从软件本身限制某些不希望公网访问的服务的监听范围。

如果软件本身支持指定监听网域，则将监听网域限制在大内网
如果软件不支持监听网域，但允许设置访问登录，则务必开启登录，并给内网网域设定免验证白名单
如果软件允许访问登录，但不支持白名单，就选麻烦也要设置好合理的密码，切勿使用 password 等弱密码
如果都不支持，考虑 lucky 或者自求多福

例子：Meta

Meta 属于第二种情况，具体的配置方法已经在上面第一个容器:配置文件中给出

例子：QB

QB 的情况也属于第二种，监听全端口，设置强密码并对 localhost 、LAN 、docker 、Tailscale 跳过验证：

例子：Aria2

Aria2 的 RPC 目前只支持监听 127.0.0.1 或 0.0.0.0 ，并且并没有网域白名单，即第三种情况，因此创建容器时请务必给 RPC 设置好一个强密码，指定密码的环境变量是SECRET：

Jellyfin 配置

如果你按照绿联云帮助中心的教程部署 Jellyfin ，那么恭喜你，这个 Jellyfin 基本只有 40%可用。你将会面临以下问题：

内置刮削源不可用
硬解解码未配置
4K HEVC 的 HDR10/Dolby Vision 无法转码
中文字库缺失，封面和字幕全是方块
IPV6 默认关闭
配置文件权限失控

想要得到一个比较完美的 Jelly server ，还需要更多的步骤。

隧道组网

在买这台 NAS 之前，我的 Jellyfin 服务器是搭建在主力 Windows PC 上的，而我的 PC 又开机启动隧道，导致我以为 Jellyfin 的 IMDB 和 TMDB 源都是开箱即用的，直到我把几个 T 的影视迁移到 NAS 后发现什么东西都刮削不出来。

我在交流群中看到有些用户会使用适配 Jellyfin 的第三方刮削源，比如 tinyMediaManager 来解决这个问题，不过我更喜欢原生的 IMDB 和 TMDB ，因为我已有的媒体库在内置源下已经全部准确识别，所以适合继续沿用。

说白了还是网络问题，解决的方法也很简单，要么改 hosts ，要么上隧道，而我肯定是义无反顾地选择上隧道的，只要在环境变量里加上这两条就好，Jellyfin 能够识别并且自动走代理：

绿联的官方教程根本没有提及这个问题。

硬解配置

Jellyfin 的硬解稍微有一点学问，但不多，总结下来大概有这么几点：

在 Docker UI 里勾选的硬件渲染实际上等价于--device /dev/dri:/dev/dri透传显卡设备，官方教程中让用户设置PUID和PGID为 0 是因为/dev/dri/renderD128和/dev/dri/card0权限为 root@600
N5105 和 N6005 的硬解设备统一都为 Intel QuickSync (QSV)
Jasper Lake GPU 不支持 VPP Tone mapping ，在“色调映射”相关选项中应当开启的是普通的 Tone Mapping
（没有真实验证过，理论上）低功耗 encoder 在这个 Openwrt 系统里应当是不可用的，不过反正这颗 CPU 功耗已经很低了
Fallback font folder path 需要放置 woff2 字体，并且大小不能大于 20MB ，我推荐 sarasa-gothic-sc-regular-nerd-font.woff2
需要勾选“Allow subtitle extraction on the fly”
H.265 encoding CRF 推荐 27 ，H.264 encoding CRF 推荐 24

附：我的个人设置

Tone Mapping 和 Direct Play

高清影视收藏早就迈入了 4K HDR 时代。现在越来越多的电影和 TV 都是动辄 HDR 、Dolby Vision 等先进编码格式，对解码工作有不小的挑战。

就我的使用经验总结，以下情况会不可避免地强制触发转码：

在不支持 HDR 的客户端观看 HDR 片源（多见于 Windows ，使用浏览器，未开启 Windows HDR ）：触发 Tone Mapping
在基于浏览器的客户端中尝试播放带有ASS 高级字幕的 HEVC 片源：触发服务端烧录
在除 Edge 之外的浏览器中尝试观看 HEVC 片源（只有 Edge 交了授权费）：触发 H264 转码
在没有授权的设备上观看 Dolby Vision P5 片源：触发 Tone Mapping

以下情况能够避免转码：

Windows 使用 Jellyfin Media Player ，或者 Jellyfin MPV Shim
使用基于 MPV 的客户端，如 vidhub
使用基于 VLC Kit 的客户端，如 swiftfin
以上 3 种选择，共同点是 HDR 内容会在本地 tone mapping ，并且具备终端字幕的处理能力，但不支持 HDR 输出。据称 MPV Shim 在配置得当的情况下能够支持 HDR 输出，但是我还没调通。
iOS 使用 native player 播放，并且同时选择 SRT 基础字幕（ iOS 的 native player 不具备高级字幕的处理能力，ASS 会触发服务端烧录，不推荐）
Apple 生态的宇宙终极解决方案 Infuse ，支持全格式+全种类 HDR 解码+HDR 输出，支持终端字幕处理
Android TV 使用 Jellyfin Media Player 或者 Kodi 客户端（解码能力遵守电视硬件和系统设置，支持终端字幕处理）

Android 手机端、Shield 、Apple TV 等环境因为我没有无法测试，希望网友们补充。

可以看到，一旦涉及浏览器和 iOS 环境，坑和雷就很多，而在原厂情况下 Jasper Lake 核显在尝试处理 HDR 编码（ DV, HDR10 and HLG ）时会转码失败，无法播放，查询 log 会有device not found字样，多见于 4K 电影和美剧。这种情况仅会在 HEVC HDR 环境发生，但并不代表 N5105/6005 的核显不支持这个规格的视频转码。Linuxserver.io 的文档已经提到了相关的问题，你需要在环境变量中加一条参数：

DOCKER_MODS=linuxserver/mods:jellyfin-opencl-intel

以开启基于 OpenCL 的 Tone Mapping 能力。本身 Jasper Lake 就不支持 VPP TM ，同时遇到上述高规格编码时普通 Tone Mapping 无法工作，所以会导致播放失败。

绿联的官方教程根本没有提及这个问题。

中文字库

Linuxserver.io 的原厂镜像并没有对 CJK 语境的支持，一旦在不支持终端字幕处理的设备上观看中文内容，就会导致中文全部变成框框、中文的媒体库封面也变成框框。在网上有很多传统教程教你用别的 ttf 字体替换系统内置的 Deja-Vu Sans ，其实 2023 年并不需要这么麻烦，Linuxserver 的镜像内部已经支持自动加载/usr/share/fonts下的字体文件，你只要用docker cp把字体放进去就好。

还有更加简单的方法，Linuxserver 镜像底层是 Ubuntu ，所以一条命令就能够解决中文环境问题：

apt update && apt install fonts-noto-cjk-extra -y

会自动在系统中安装 Noto CJK （思源黑体）。系统显示用的非衬线体我只推荐两个：Noto和更纱黑体，只有他们对字形的支持能够覆盖到操作系统的所有显示需求。

绿联的官方教程根本没有提及这个问题。

IPV6

Jellyfin 才在半年之内的版本实现对 IPV6 的支持，而且出厂似乎默认没有开启。记得去 Networking-IP Protocols 把 Enable IPV6 勾选上

权限更改

参考前文，因为调用 GPU 必须指定用户为 root ，所以默认情况下镜像产生的所有配置文件和文件夹通过 SMB 访问没有写入权限，因此我们必须在环境变量中加入：

UMASK=000

（可选）主题优化

默认的主题对比 Emby 稍微有些死板，不够灵动，所以我去 Github 找到了一套我最喜欢的主题Ultrachromic，并且进行了一点点优化配置，供各位参考

@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/fixes.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/base.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/accentlist.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/rounding.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/smallercast.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/episodelist/episodes_compactlist.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/header/header_transparent.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/login/login_minimalistic.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/type/dark_withaccent.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/fields/fields_noborder.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/cornerindicator/indicator_floating.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/titlepage/title_simple-logo.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/progress/floating.css');
@import url('https://cdn.jsdelivr.net/gh/CTalvio/Ultrachromic/effects/glassy.css');
@import url("https://cdn.jsdelivr.net/gh/prayag17/Jellyfin-Icons/round.css");/* Fonts */@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+SC:wght@300;400;500;700&display=swap');
@import url('https://fonts.googleapis.com/css2?family=Quicksand:wght@500;600;700&display=swap');body, h1, h2, h3, h4 {  font-family: 'Quicksand', 'Noto Sans SC', sans-serif;
}.emby-textarea {  font-family: monospace;  font-size: 10pt;
}/*Style backdrop*/.backdropImage {filter: blur(18px) saturate(120%) contrast(120%) brightness(20%);}/*Login background*/#loginPage {background: url(/* 公共图床的背景图片 URL ，推荐 1080P */) !important;}/*Accent and rounding*//* 可以调配你自己喜欢的颜色 */:root {--accent: 195,140,255;}:root {--rounding: 12px;}/* Disable carousel *//* 在大屏幕设备上关闭首页卡片的横向滚动，更加易用 */@media all and (min-width: 50em) {  .homePage .emby-scroller {    margin-right: 0;
  }  .homePage .emby-scrollbuttons {    display: none;
  }  .homePage .itemsContainer {    flex-wrap: wrap;
  }
}

（可选）进度条预览

我们使用Jellyscrub来提供进度条预览功能，这个插件能在 Plugins-Catalog 直接安装，并且与各种客户端、浏览器和第三方插件的适配都很好：

请记得在插件设置里把 HW Acceleration 更改为 No Encode （ Intel 核显不支持 mjpeg 编码，所以不能选择 Full ），不然会通过 CPU 编码，整台机器发烧到天昏地暗，速度还慢得出奇。

同时，上面提到的 DOCKER_MODS 环境变量还会影响这个插件的缩略图采集，如果没有打 MOD ，这个插件也不支持生成高规格 HDR 视频的进度条预览图。

（可选）观看统计

观看统计通过插件 Playback Report 实现，直接从 Plugins-Catalog 安装就好，在你的影视库用户量比较大的时候能够给你一个统计报告，观察大家都喜欢看什么：

（额外）命名守则

https://jellyfin.org/docs/general/server/media/shows/

遵守 Jellyfin 官方的命名守则能够让你更有序地管理剧集和番剧资源，目前我库里的所有番剧内容都会按照 Jellyfin 的命名守则重新改名字，用 Power Rename 正则表达式其实挺方便的：

TMDB 本身就有番剧资源的元数据，并不依赖 AniDB 等第三方插件（除了里番、OVA 等），只要稍加改名就能够正确识别：

Linux 补完计划

固件破破烂烂，我们缝缝补补
s/1ejEUsEYZzIi5vu5NSrej0g?pwd=9uv7

Busybox

在《深入解析》的时候我们就已经知道了这个系统用的是 busybox+ash 。但是，更离谱的是，UGOS 在编译时忽略了接近 50%的 busybox 命令，导致 shell 基本上处于一个半残废状态。

为了补足功能的缺陷，我连夜学习编译了一个静态库版本的 busybox ，包含了官方出厂能用的 310 条命令，并且对比系统固件所缺的命令列表，总结出了缺失命令，写了一个脚本来创建动态链接，缝补好这个残缺的 busybox：

#!/bin/bashbusybox_path="/opt/bin/busybox"target_dir="/usr/bin/"items=("acpid" "add-shell" "adjtimex" "ar" "arch" "arp" "base32" "base64" "bc" "beep" "blkdiscard" "bootchartd" "bzip2" "cal" "chat" "chpst" "chrt" "chvt" "cksum" "comm" "conspy" "cpio" "crc32" "cryptpw" "cttyhack" "dc" "deallocvt" "depmod" "dhcprelay" "diff" "dnsd" "dnsdomainname" "dos2unix" "dpkg" "dpkg-deb" "dumpkmap" "dumpleases" "ed" "eject" "envdir" "envuidgid" "ether-wake" "expand" "factor" "fakeidentd" "fallocate" "fatattr" "fbset" "fbsplash" "fdflush" "fdformat" "fgconsole" "fold" "freeramdisk" "fsck" "fsck.minix" "fsfreeze" "fstrim" "ftpd" "ftpget" "ftpput" "getopt" "getty" "hd" "hexedit" "hostid" "hostname" "httpd" "hush" "ifenslave" "ifplugd" "inetd" "install" "ionice" "ipaddr" "ipcalc" "ipcrm" "iplink" "ipneigh" "iproute" "iprule" "iptunnel" "kbd_mode" "killall5" "klogd" "last" "link" "linux32" "linux64" "linuxrc" "loadfont" "loadkmap" "logname" "lpd" "lpq" "lpr" "lsscsi" "lzcat" "lzma" "lzop" "makedevs" "makemime" "man" "mdev" "mesg" "microcom" "mim" "mkdosfs" "mkfs.minix" "mkfs.reiser" "mkpasswd" "more" "mountpoint" "mt" "nameif" "nanddump" "nandwrite" "nbd-client" "netcat" "nl" "nmeter" "nohup" "nproc" "nsenter" "od" "openvt" "paste" "patch" "pipe_progress" "popmaildir" "powertop" "printenv" "pscan" "pstree" "raidautorun" "rdate" "rdev" "readahead" "readprofile" "realpath" "reformime" "remove-shell" "renice" "resume" "rev" "rpm" "rpm2cpio" "run-init" "run-parts" "runlevel" "runsv" "runsvdir" "script" "scriptreplay" "seedrng" "sendmail" "setarch" "setconsole" "setfont" "setkeycodes" "setlogcons" "setpriv" "setserial" "setsid" "setuidgid" "sha1sum" "sha3sum" "sha512sum" "showkey" "shred" "shuf" "slattach" "smemcap" "softlimit" "split" "ssl_client" "stty" "sulogin" "sum" "sv" "svc" "svlogd" "svok" "syslogd" "tac" "tc" "tcpsvd" "telnet" "telnetd" "tftp" "tftpd" "truncate" "ts" "tsort" "tty" "ttysize" "tunctl" "ubiattach" "ubidetach" "ubimkvol" "ubirename" "ubirmvol" "ubirsvol" "ubiupdatevol" "udhcpc6" "udhcpd" "udpsvd" "uevent" "unexpand" "unix2dos" "unlink" "unlzma" "unshare" "unxz" "users" "usleep" "uudecode" "uuencode" "vconfig" "vlock" "volname" "wall" "watchdog" "who" "whoami" "whois" "xxd" "xz" "xzcat" "zcip")for item in "${items[@]}"; do
    ln -s "$busybox_path" "$target_dir$item"
    if [ $? -eq 0 ]; then
        echo "Created symlink for $item"
    else
        echo "Failed to create symlink for $item"
    fidone

请根据自己的情况修改 busybox binary 的存放位置。

其它软件

rsync 对于高级 Linux 玩家不可或缺，同样是由于 libc 的原因，从 opkg 安装的 rsync 无法运行。所以我又编译了一个 static 版本的 rsync ，还是一样：

ln -s /opt/bin/rsync-static /usr/bin/rsync

同理，还有：

iozone ，一个用户 Linux IO 性能测试的软件
iotop ，一个类似 top/iftop/nvtop 的，面向系统 IO 的监控软件（但是在 UGOS 运行一段时间后会出现行错位，不太好用）

用户态 nfsd

论坛里面还是有高手的，有一位大哥实现了用户态 nfs 软件 nfs-ganesha 的部署，并且看起来像是自己编译的安装包、自己写的 init.d 配置文件，移步论坛帖子查看：

https://bbs.ugreengroup.com/forum.php?mod=viewthread&tid=10961&highlight=ganesha

它写的 init.d 配置文件默认只分享一个目录，我进行了一些适当的修改，具体可以参照帖子里最新的一楼。

用户反馈模式

最后这一部分是一个小吐槽。

买之前我看博主是这样吹的：

买之后固件更新失踪一个月、官方更新路线失踪 2 个月，官方四处叫天天不应、叫地地不灵，技术支持客服 80%的时间在用套话跟你聊天。

网上面的很多博主都会说绿联听取用户意见，那我就不得不说说绿联现在的用户反馈模式了：

外网，全部都是投放和软文，并且定位都是轻度体验和开箱，绝口不提深度的软件内容，没有任何公开的用户讨论社群
论坛，admin 直接和用户打交道的地方，必须购买产品并且注册账号才能够访问，论坛本身有 token 验证，不携带 token 拒之门外，放一个二维码给你扫
2.1 这一步将用户的沟通渠道从公网收缩到了买了产品、注册而且会上论坛的人
2.2 现在论坛的建议反馈区域已经没有 admin 回答，admin 只活跃在解答用户疑问的“求助解答”板块
11 月中绿联官方短暂复活，发布帖子邀请用户加入“绿联私有云官方交流群”，方式是添加一个“工具人”，提交你的账号、设备 SN 码，经核实才会允许入群，群规模 500 ，我加入的是第 5 群
3.1 这一步将用户的沟通渠道进一步收缩到了 3000 人
3.2 我时不时会看到自己那篇《深入解析》被转载到群里交流，但是好像没怎么发现是我写的
群里面有一个 bot 提供基本的解答，并且 500 人的大群，意见反馈和需求统一需要主动加群里的 1 个人私聊，没错，只有这 1 个人，收缩比例 1:500：
目前更新计划已经彻底不公开，论坛“官方公告”的升级规划已经全部成为过去式，如果想要了解系统的更新计划，现在的做法是蹲点等待“内测组报名”不定期开启，每次内测只会邀请数十名用户直接面对产品组体验 beta 固件，免费测试打工，除此之外请排队找上图的这位爷。
然后群里日常吐槽系统问题，官方的机器人突然活人上号出来让我们不要诋毁，被我骂了

深入浅出玩转绿联 UGOS (上)

Wed, 31 Jan 2024 13:29:07 +0800

文章一些部分用词有点晦涩难懂，是因为有可能文章也会转载到别的平台，所以用了一些别名指代
比如：隧道 → 代理，内核 → C???h ，Meta → C????.meta

折腾这个 NAS 的系统，就像我以前学 coding 的时候看的那些教学书一样，《深入浅出》，有一种完全了解病根了才想得出对策的探索感。当然，我不希望一个正常的 NAS 系统需要用户自己探索这些。

接下来的教程全部都基于继续使用 UGOS 的前提下。出于各种各样的原因，更换系统的沉没成本已经大到无法接受，导致只能在不刷系统的情况下继续使用，那么以下教程想要教你部署的东西就是一台 NAS 业务能力基础中的基础，好坑都埋在基础之中。

这篇教程在介绍操作的时候都会讲解一下背后的大致原理，目的在于让所有入门者都知其然而知其所以然。只想无脑 copy-paste 命令跑通的伸手党用户大可去参阅其他人写的 pdf 教程，在绿联社区里有非常多，只需要回复一句“感谢楼主分享”即可获得。

目标

这个教程的目标只有 2 个：

搭建一个第三方媒体库
让公网也能访问它

于是，你以为要满足这个需求，平台弄成这样就好了：

实际上最后要弄成这样（懒得弄箭头了，将就看吧）：

紧急通知

①
先前 Intel N5105/6005 平台的 DSM 因为没有 Intel 核显驱动导致无法硬件解码的问题一直迟迟不能得到解决。但最近随着群晖 SA6400 系列平台 toolchain 开源，有开发者成功借助该平台的 toolchain 编译出 Intel i915 驱动，意味着核显硬解问题被突破，阻挡黑群的最后一座大山已经被顺利拆除。
https://xpenology.com/forum/topic/69865-i915-driver-for-sa6400/
因此，（刷了 DSM 的）绿联 DX4600 Pro 已经成为全网性价比最高的 4 盘位 NAS 成品机！

②
这篇文章暂停了一段时间，因为绿联官方说“即将迎来固件更新”，所以我就暂停了一阵子，因为怕现在写出来的内容会在系统更新后过时。
在官方的计划路线失踪了 1 个月、固件更新停摆了 2 个月之后，我们终于在 12 月 5 日迎来了 v4.9.0 的重大更新：他们花了 2 个月时间重构了相册，其他部分几乎是丝毫没变，因此本篇章所涉及的部署教程没有受到任何影响。
另外，我在《深度分析》中吐槽相册的问题，在这个重构的相册 2.0 中基本都被解决。

Tailscale

众所周知，绿联云所谓自带的 P2P 只有 APP 能够使用。APP 以外的任何服务，包括 docker 、你在系统环境内跑的各种各样的东西，公网访问还是要自己解决。

这篇教程将会使用大内网模式，即以 Tailscale 作为终端组网，其它所有想要访问 NAS 的用户都需要加入大内网。至于理由，我能够编出很多：

不依赖公网 IP
因为不依赖公网 IP ，所以相比 DDNS 等方案可操作性更强
因为不用 DDNS 域名，所以无需经过备案等繁琐操作
即使没有 TLS 证书，也是端到端加密，数据隐私有保障，不怕 HTTP 明文访问被“反诈中心”找上门
邀请用户入网需要二次验证，能够有效管控加入网络的用户
Tailscale 生态中的 Exit Node 、Taildrop 、MagicDNS 功能为用户间的联系提供了极大便利，有 MagicDNS 和手动定义 DNS 功能也能够保证访问体验不繁琐，不用记 IP
只有 Tailscale 真真正正做到了全平台覆盖，（几乎）任何内核完备的操作系统都能够运行 Tailscale ，包括容器。
（与此对比的是 ZeroTier ，它的 iOS 端不支持自定义 moon ，Android 官方客户端不支持自定义 Moon ）
开放，全平台客户端一键填写login-server，即使用 Headscale 自建网络客户端也无需进行接入 Moon 那种繁琐的步骤
（ Planet 仍是私有化产物，即 iOS 没有办法连接自建 planet ）
穿透能力极强，甚至能够带动其它的 P2P 方案在上层线路打洞
（想必很多人没有体验过 ZeroTier 组网能 ping 通但是数据一直阻塞，启动 Tailscale 的瞬间两款软件的 P2P 突然全通了的事情）
我是 wireguard 神教拥护者

废话说完了，我们直接开始。Tailscale 客户端在 unix 系统需要使用/dev/net/tun来提供网络隧道，因此在容器中使用需要手动透传 device ，这一步操作在绿联私有云 APP 的 docker 管理器 UI 中无法实现。此外，受限于 docker 的网络机制，在容器中运行 Tailscale 仍有诸多限制。

我认为，在一个容器层级里跑 wireguard 多多少少是脑子出了问题。因此，我们将会把 Tailscale 直接安装在系统里，为系统全局的网络提供穿透服务。

添加 OPKG 软件源

vim /etc/opkg/distfeeds.conf

我们能够看到系统默认只在 distfeeds 里启用了 SNAPSHOT 源，基本上等同于常规的软件都不可用，所以需要手动添加 openwrt 22.03 的 packages：

src/gz openwrt_packages https://archive.openwrt.org/releases/22.03.0/targets/x86/64/packages
src/gz openwrt_base https://downloads.openwrt.org/releases/22.03.0/packages/x86_64/base

:wq保存，先更新源再安装依赖：

opkg update
opkg install libustream-openssl ca-bundle

安装 Tailscale

仅需一条命令

opkg install --force-depends tailscale tailscaled

安装进程一定会失败，Tailscale 无法运行，在后处理的时候会提示/usr/sbin/tailscale: not found，具体原因参考我们在深入解析中的 OPKG 分析环节。但是通过 OPKG 安装 tailscale 包，它会帮我们配置好/etc/init.d等配置文件，因此这一步是必要的。

好在，Tailscale 官方的 packages release 为普通 Linux 编译好了一份静态链接库的版本，接下来我们要做的是去 https://pkgs.tailscale.com/stable/#static 下载 amd64 平台的 Static binaries ，并且替换掉 OPKG 释放到系统里的 binaries 。

Static binaries 对比 OPKG 包安装的二进制文件：

下载这个：

通过各种方式上传到服务器里，大概执行以下命令覆盖并授予执行权限：

tar zxvf tailscale<tab>
cp tailscale /usr/sbin
cp tailscaled /usr/sbin
chmod +x /usr/sbin/tailscale*    # 或者模仿绿联的权限模式，777

然后通过init.d尝试启动 tailscale 服务，并查询是否 running：

/etc/init.d/tailscale restart
/etc/init.d/tailscale status

你会看到蹦出了一系列关于 iptables 的报错，这些错误都是因为 tailscale 尝试使用 iptables 去编辑 systemd.target 产生的，而众所周知 openwrt 并没有 systemd ，因此可以不用理会。

需要重点关注的是这些 log 之间是否有出现/usr/sbin/iptables: not found之类的错误，如果有，请参考 Troubleshooting ，否则代表后台服务 tailscaled 已经启动成功。

日志参考：

root@UGREEN-????:~# /etc/init.d/tailscale restart
logtail started
Program starting: v1.52.1-t75d3c9385-g3e9627f3b, Go 1.21.3: []string{"/usr/sbin/tailscaled", "--cleanup"}
LogID: ************************************
logpolicy: using system state directory "/var/lib/tailscale"dns: [rc=unknown ret=direct]
dns: using "direct" mode
dns: using *dns.directManager
......
logtail started
Program starting: v1.52.1-t75d3c9385-g3e9627f3b, Go 1.21.3: []string{"/usr/sbin/tailscaled", "--cleanup"}
LogID: ************************************
logpolicy: using system state directory "/var/lib/tailscale"dns: [rc=unknown ret=direct]
dns: using "direct" mode
dns: using *dns.directManager
deleting [-j ts-input] in filter/INPUT: running [/usr/sbin/iptables -t filter -D INPUT -j ts-input --wait]: exit status 2: iptables v1.8.7 (legacy): Couldn't load target `ts-input':No such file or directoryTry `iptables -h' or 'iptables --help' for more information.deleting [-j ts-forward] in filter/FORWARD: running [/usr/sbin/iptables -t filter -D FORWARD -j ts-forward --wait]: exit status 2: iptables v1.8.7 (legacy): Couldn't load target `ts-forward':No such file or directoryTry `iptables -h' or 'iptables --help' for more information.deleting [-j ts-postrouting] in nat/POSTROUTING: running [/usr/sbin/iptables -t nat -D POSTROUTING -j ts-postrouting --wait]: exit status 2: iptables v1.8.7 (legacy): Couldn't load target `ts-postrouting':No such file or directoryTry `iptables -h' or 'iptables --help' for more information.deleting [-j ts-input] in filter/INPUT: running [/usr/sbin/ip6tables -t filter -D INPUT -j ts-input --wait]: exit status 2: ip6tables v1.8.7 (legacy): Couldn't load target `ts-input':No such file or directoryTry `ip6tables -h' or 'ip6tables --help' for more information.deleting [-j ts-forward] in filter/FORWARD: running [/usr/sbin/ip6tables -t filter -D FORWARD -j ts-forward --wait]: exit status 2: ip6tables v1.8.7 (legacy): Couldn't load target `ts-forward':No such file or directoryTry `ip6tables -h' or 'ip6tables --help' for more information.[RATELIMIT] format("deleting %v in %s/%s: %v")
cleanup: list tables: netlink receive: invalid argument
flushing log.
logger closing down

root@UGREEN-????:~# /etc/init.d/tailscale statusrunning

登录 Tailscale

由于这个绿联系统的各种组件错综复杂，端口开放关系混乱，所以我们希望 Tailscale 尽可能小地去影响系统的其它网络服务运行，具体来说：

不去接管系统的 DNS
[Openwrt 系统必须]不去更改 iptables 规则
[可选]不去创建子网路由

这会导致：

本机的 MagicDNS 失效，无法在本机通过域名访问其它设备，但是被访问不受影响
Subnet Router 相关功能可能受限

考虑到 NAS 只是一个提供服务的受访终端，上述缺陷可以忽略不计。

因此，启动 Tailscale 必须使用以下参数：

tailscale up --netfilter-mode=off --accept-dns=false

如果你使用自建的 Headscale 服务器：

# 即使没有域名也建议使用 ZeroSSL 给纯 IP 上个 TLS 证书tailscale login --login-server https://<your-server> --netfilter-mode=off --accept-dns=false

尽量避免使用--accept-routes flag ，在不传入这个 flag 的时候默认是 false 。必须使用--netfilter-mode=off参数！

接下来的验证步骤就跟普通 Linux 机是一样的，登录完成后即可使用，可以使用netcheck验证。

root@UGREEN-????:~# tailscale netcheck2023/11/25 15:37:41 portmap: [v1] Got PMP response; IP: 100.64.***.***, epoch: 1899682023/11/25 15:37:41 portmap: [v1] Got PCP response: epoch: 1899682023/11/25 15:37:41 portmap: [v1] UPnP reply {Location:http://192.168.1.1:5351/rootDesc.xml Server:MiWiFi/x UPnP/1.1 MiniUPnPd/2.1 USN:uuid:**********************::urn:schemas-upnp-org:device:InternetGatewayDevice:1}, "HTTP/1.1 200 OK\r\nCACHE-CONTROL: max-age=120\r\nST: urn:schemas-upnp-org:device:InternetGatewayDevice:1\r\nUSN: uuid:***********************::urn:schemas-upnp-org:device:InternetGatewayDevice:1\r\nEXT:\r\nSERVER: MiWiFi/x UPnP/1.1 MiniUPnPd/2.1\r\nLOCATION: http://192.168.1.1:5351/rootDesc.xml\r\nOPT: \"http://schemas.upnp.org/upnp/1/0/\"; ns=01\r\n01-NLS: 1700703935\r\nBOOTID.UPNP.ORG: 1700703935\r\nCONFIGID.UPNP.ORG: 1337\r\n\r\n"2023/11/25 15:37:41 portmap: UPnP meta changed: {Location:http://192.168.1.1:5351/rootDesc.xml Server:MiWiFi/x UPnP/1.1 MiniUPnPd/2.1 USN:uuid:*************************::urn:schemas-upnp-org:device:InternetGatewayDevice:1}Report:
	* UDP: true
	* IPv4: yes, ***.***.***.***:*****
	* IPv6: yes, [240e::****]:*****
	* MappingVariesByDestIP: false
	* HairPinning: true
	* PortMapping: UPnP, NAT-PMP, PCP
	* CaptivePortal: false
	* Nearest DERP: Headscale Embedded DERP TC Shanghai 4Mbps
	* DERP latency:
		- headscale: 30.4ms  (Headscale Embedded DERP TC Shanghai 4Mbps)
		- sfo: 168.1ms (San Francisco)
		- hkg: 174.4ms (Hong Kong)
		- lax: 175.6ms (Los Angeles)
		- tok: 178.7ms (Tokyo)
		- den: 187.6ms (Denver)
		- sea: 187.8ms (Seattle)
        ......

配置防火墙

由于我们使用--netfilter-mode=off模式登录 Tailscale ，所以软件不会去创建防火墙规则，我们需要根据Openwrt Wiki 的教程自行处理。实际上从 uci 内置规则来看，UGOS 默认是放行所有流量出入的，但是禁止了转发，可能会导致穿透能力被削弱的问题，因此我们还是按照教程走一遍：

Create a new unmanaged interface via LuCI: Network → Interfaces → Add new interface
Name: tailscale
Protocol: Unmanaged
Device: tailscale0
Create a new firewall zone via LuCI: Network → Firewall → Zones → Add
Name: tailscale
Input: ACCEPT (default)
Output: ACCEPT (default)
Forward: ACCEPT
Masquerading: on
MSS Clamping: on
Covered networks: tailscale
Allow forward to destination zones: Select your LAN (and/or other internal zones or WAN if you plan on using this device as an exit node)
Allow forward from source zones: Select your LAN (and/or other internal zones or leave it blank if you do not want to route LAN traffic to other tailscale hosts)
Click Save & Apply

这段教程是面向 luci 的，然而我们的系统并没有 luci ，所以翻译成 uci 命令就是这样：

uci add network interface
uci set network.@interface[-1].name='tailscale'uci set network.@interface[-1].proto='none'uci set network.@interface[-1].ifname='tailscale0'uci commit network

uci add firewall zone
uci set firewall.@zone[-1].name='tailscale'uci set firewall.@zone[-1].input='ACCEPT'uci set firewall.@zone[-1].output='ACCEPT'uci set firewall.@zone[-1].forward='ACCEPT'uci set firewall.@zone[-1].network='tailscale'uci set firewall.@zone[-1].masq='1'uci set firewall.@zone[-1].mtu_fix='1'uci commit firewall

uci add firewall forwarding
uci set firewall.@forwarding[-1].src='tailscale'uci set firewall.@forwarding[-1].dest='wan'uci commit firewall# 可选uci add firewall forwarding
uci set firewall.@forwarding[-1].src='wan'uci set firewall.@forwarding[-1].dest='tailscale'uci commit firewall

创建完这些规则之后，我建议重启，或者如果你不想重启：

/etc/init.d/network restart
/etc/init.d/firewall reload    # 使用 restart 命令强行重启防火墙会导致 docker 网络崩溃

Troubleshooting

如果出现 iptables not found ，可能是因为通过 OPKG 或者其他手段安装的一些包影响了 iptables 的调用。以我的经验为例，如果参照了 Openwrt 的官方教程去手动安装了iptables-nft包的话，就会导致 iptables 失效，原厂环境下实际上是能用的。

无需担心因为安装了这个包，系统的 iptables 直接失能。因为iptables-nft本质上是给 iptables 相关的几个命令添加了指向/usr/sbin/xtables-legacy-multi的软链接，并没有替换本身可以执行的二进制。但是很魔幻的事情是，通过 OPKG 安装的软链接是失效的，但是你将它删除，再手动创建一遍相同的链接却又可以正常使用，目前还没找出原因。

所以：

rm /usr/sbin/iptables
rm /usr/sbin/ip6tables
ln -s /usr/sbin/xtables-legacy-multi /usr/sbin/iptables
ln -s /usr/sbin/xtables-legacy-multi /usr/sbin/ip6tables

这会保证 tailscaled 初始化的时候能够正常运行，否则整个 tailscale 服务都无法拉起。

Docker 的网络搭建

Docker 的 bridge 网络会随机为容器分配 NAT 地址，为了方便容器内部之间互相访问，它为具名网络提供了通过 container name 解析到 IP 的能力。

在这个系统架构中，我们决定把隧道服务搭建在容器里，并且只提供被动的 Proxy 接口访问能力，为一些需要代理的容器提供服务，不干扰系统其它网络环境的运行，做到职责最小化。

为了更好管理需要隧道的容器，我们将会为它专门创建一个 NAT 网络，并把需要隧道的容器都放在这个网络里。

给 bridge 开启 IPV6

Docker 默认的 bridge 网络是关闭 IPV6 的，所以我们需要通过更改配置的方法主动开启 bridge 的 IPV6 。这一步并不影响其它容器的部署，只是为了给整个 docker 平台创建一致且可用的 IPV6 环境。

vim /etc/docker/daemon.json

{    "data-root": "......",    "log-level": "warn",    "iptables": true,    "api-cors-header": "*",    "hosts": [        "unix:///var/run/docker.sock",        "tcp://127.0.0.1:9375"
    ],    "registry-mirrors": [        "https://registry.docker-cn.com"
    ],
    /* 加上这几行配置 */    "ipv6": true,    "fixed-cidr-v6": "2001:db8:abc1::/64",  // 并不需要严格遵守这里的 cidr ，任意一个内网 IPV6 网段皆可    "experimental": true,    "ip6tables": true}

保存后在绿联私有云 APP 的 docker 管理页中重启，这时候你就能够看到 bridge 网络已经具备 IPV6 地址。

创建一个新的 NAT 网络

这一步不需要命令行，直接在 APP 操作即可。网络名称任选，子网和网关的填写方法请复习网络基础知识。如果实在不知道该选什么网段，就去问 chatGPT 给你随机生成一个。一个例子：

第一个容器

所谓大内网计划，我们要部署的第一个容器一定是隧道。我们这里以 meta 为例，虽然这个内核的一系列衍生项目全部都删库跑路，但是我在他们消失于互联网之前备份下了：

所有的源码
最近 3 个版本 stable 和若干 nightly 的 releases
最近 3 个以上版本的 docker image tar 包

注：有需要的话请留下联系方式

将clash-meta-pr-837.tar上传到 NAS 中，并在 SSH 通过以下命令导入 tar 包镜像，它会自动识别，然后使用这个镜像创建容器：

docker load <image>.tar

控制台“从设备导入”tar 包，使用的似乎是docker import，会丢失所有的元数据信息。

因为 bridge 网络内支持通过 container name 访问，所以在这里我们部署的所有容器，都使用‘.’作为分隔符号，好让请求看起来更像是一个 URL ，比如这样：

容器大概的配置如下：

Config	Value
-i	True
-t	True
--restart	unless-stopped
容器能力	建议勾选`NET_ADMIN`和`NET_BROADCAST` （不一定正确）
网络	你刚建的`tunnel.net`
存储空间映射	`存储空间/config/clash:/root/.config/clash/`, RW
端口映射	TCP 7890:7890, TCP 9090:9090, TCP+UDP 1053:1053

使用 meta ，一是因为它能够默认支持订阅管理，不用像原生内核那样只能够指定一个本地的配置文件，方便远程维护和更新；二是因为它的订阅与规则解耦，我们可以无视订阅附带的规则内容自行添加一些网络环境相关的规则（也就是 Mixin 和 Parser ）。

配置文件

直接照抄虚空终端 Docs 里的懒人配置，再把自己的订阅链接填上就好： https://wiki.metacubex.one/example/#_2 ，并且我推荐直接把geox-url节点里三个地理信息文件手动下载下来放到你的存储空间 config 映射文件夹里去，在 docker 容器内自动下载失败的概率比较大。

但我们需要做一些改动，首先需要把 tun 模式直接关闭：

tun:
  enable: false
  ......

其次，主控相关的规则也需要有所更改：

mode: rule
ipv6: true        # 如果你的网络环境支持 IPV6 ，记得打开
log-level: info
allow-lan: true   # 必须允许 LAN 访问
bind-address: '*' # 当系统同时具有多张网卡（ tailscale 虚拟出来的 tun 网卡）时，
                  # 这里只能够填'*'全监听，因为该条目只支持 string ，不支持 array
authentication:   # 建议随机一个非常强的用户和密码，防止被公网使用
  - "YouCannotUseThis:ICannotUseThisQAQ"
skip-auth-prefixes:
  - 127.0.0.1/8               # 本地回环
  - ::1/128                   # 本地回环 IPV6
  - 172.19.0.0/16             # Docker network 网段
  - 192.168.1.0/24            # 路由器 LAN
  - 100.***.***.*/22          # Tailscale 网段
  - fd7a:****:****::/48       # Tailscale IPV6 网段
  - 2001:db8:abc1:1::/64      # Docker network IPV6 网段
  - 240e:3b5:34e1:93f0::1/64  # 路由器 LAN IPV6
mixed-port: 7890
unified-delay: false
tcp-concurrent: true
external-controller: 0.0.0.0:9090 # 控制端口监听全网段

这里我们设置了隧道监听全网，但是配置了一个非常复杂（不用记）的 Authentication 验证，以确保来自公网的用户不能够白嫖，同时放行四个网段：localhost 、docker network 、tailscale 、LAN ，在这 4 个网段内的用户可以正常访问隧道。

接下来我们还要修改 DNS 和 Rules 的相关规则，使得内核能够识别来自容器间的域名和 IP 段，将他们放行，否则默认情况下会被丢进 match 规则从而导致请求方向失控。

dns:
  enable: true
  listen: :1053
  ipv6: true
  enhanced-mode: fake-ip
  ......
  nameserver:
    - ......
    - 127.0.0.11    # Docker 对容器提供的 DNS 地址，非常重要
                    # 没有这条将导致内核无法解析 container 名
  ......
  nameserver-policy:
    "geosite:cn,private":
      - https://doh.pub/dns-query
      - https://dns.alidns.com/dns-query

rules:
  # 将你的容器名和 docker network 网段全部指定为 DIRECT ，放在配置最前面
  - DOMAIN-SUFFIX,jellyfin.server,DIRECT
  - DOMAIN-SUFFIX,metatube.server,DIRECT
  - DOMAIN-SUFFIX,*.downloader,DIRECT
  - IP-CIDR,172.19.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,2001:db8:abc1:1::/64,DIRECT,no-resolve
  - ......

一些容器一旦在环境变量中指定了HTTP_PROXY和HTTPS_PROXY后，所有的 request 流量都会绕它走一圈，因此需要配置这样的放行规则，以避免请求走丢。

当配置文件改写好，三个 geox 也放在 config 文件夹里后，就可以启动容器待命。

远程管理

远程管理不用自建服务器。Meta 提供了一个配套的前端项目 MetaCubeXD ，并且写成了 PWA 应用。

因为我们在 LAN 互访都是基于 HTTP 的，所以正常情况下直接打开他们的 Demo 页，即 https://metacubexd.pages.dev/会被浏览器安全策略阻止，无法连接到内核。我建议直接点击 Chrome 浏览器右上角的安装，在本地生成一个快捷方式：

然后在 chrome://settings/content 里搜索 pages.dev ，找到 metacubexd ，将“不安全内容”的权限设置为允许：

现在，通过 metacubexd PWA 即可访问内核。虽然顶部会有一个比较丑的“不安全”Banner ，但无伤大雅，能用。

如果你想要自建 Docker ，mkv28/metacubexd镜像似乎是第三方作者封装的，很久没有更新，版本已经严重过时，还是推荐使用官方 demo 安装 PWA 。

互访案例

现在以一个 Jellyfin/Emby 使用的面向特定领域的资源刮削插件服务后端 metatube 为例，这个镜像已经支持在环境变量中指定HTTP_PROXY和HTTPS_PROXY，所以我们直接将这个容器创建到 tunnel.net 中，同时指定相关的环境变量：

与此同时，在 Jellyfin Plugin 设置里，指定后端地址为 container name ，端口是容器内部定义的 PORT，而不是在容器启动时指定的对外的映射端口：

接下来，尝试请求刮削一个视频的 metadata ，在 docker logs 中查看内核的连接走向：

无论是 SRC 还是 DST 的路由都没有问题。

Docker 挂载公共空间的方案

对于大多数使用 NAS 的用户而言，把自己收集的影视内容放到公共空间供其他人观看下载，同时把文件映射到自建的媒体服务器，是一个正常不过的需求。但是绿联的脑缺产品经理剑走偏锋，创新地想出了“Docker 不能挂载公共空间”的机制，为他的聪明点赞！

好在 docker 是一个遵守 Linux 规范的软件，所以在挂载 bind volume 时，允许通过软链接进行寻址。因此现阶段的解决方案是，在私人空间里单独腾出一个文件夹，创建你想要访问公共空间地址的软链接：

ln -s <公共空间位置> <私人空间位置>

在我这里，所有的软链接都放在私人空间中名为 public-mapping 的文件夹，方便管理。你在挂载目录的时候可以挂载到软链接本身，也可以沿着软链接继续挂载其子文件夹，都没有问题。

我看到有些教程教人用硬链接，不要使用硬链接，除非你知道自己在做什么！

不要使用硬链接，除非你知道自己在做什么！

为什么 docker 不能挂公共空间？

让我们复习《深入解析》吧：

某些 docker 镜像支持通过 PGID 和 PUID 环境变量指定宿主机的用户身份，这个身份会影响 bind volume 产生的文件属性，并且假设默认的 permission mask 是 022 的话，产生的数据和配置文件通过“网络账户”登录的 SMB 是没有修改权限（ 755 ）的，在修改映射到硬盘的配置文件时会出现一些麻烦。

其实这只是一个潜在的问题，因为 SMB 根本没有开放给非管理员使用，就算影响也只会影响管理员自己挂的 SMB 。

深入解析绿联云 DX4600 Pro UGOS 系统 (2)

Wed, 31 Jan 2024 13:27:35 +0800

OK ，讲了那么多系统底层的东西，接下来让我们看看与用户打交道最直接的，软件层级的用户交互体验。

真正上手体验过，你才会明白大伙之前对张小龙的态度有点过于严格了，他可能真的算是相对比较好的产品经理。

套件分析：文件管理

2023 年很少能够找到一个连 Explorer 都做得有点问题的软件开发商了。我们都知道绿联的这套东西是基于 Electron 的前端项目，所以里面有相当一部分交互被受限于纯前端的逻辑。

首先是这个前进后退键。说起来你可能不信，在 Explorer 中浏览文件，你不能够跳跃式地浏览目录，因为顶上的地址栏，是一个装饰品，你不能在上面键入任何的路径或者快速跳转。想要进入到某个目录，你只能从根目录一路递归到你想到达的地方，然后用多了几次你会发现，这两个箭头的逻辑是反 PC 的：

「后退」键实际上是../，就是 Windows Explorer 里面的上移，后退到父目录
「前进」在浏览绝大多数目录的时候它都是灰色的，只有你选中了一个文件夹，或者当前路径下只有一个文件夹时它才会亮起——就是说，它的作用是代替双击?
这两个键不绑定监听鼠标侧键，鼠标侧键在这个软件里没有任何用处
也就是说文件管理不记录你任何的访问历史路径，你只能递归查找（除非“添加到快捷入口”或“桌面快捷方式”）
后退/前进键的功能对于左侧侧边栏来说是独立的，左侧侧边栏跳转的每一条导航视作一个 Page 的话，这两个键只对 Page 内部有效
（纯粹的前端逻辑，Navigation 页面路由、组件隔离）

来看看你微软爹是怎么做 Explorer 的……

其次就是当我上传文件的时候，它总是会先问我，究竟是选择跳过、替换还是保留两者，而无论你要导入的文件是否存在重复。就好像是我高考先把志愿报了再进考场考试一样。那我肯定是希望当拷贝的时候把所有的冲突项记录下来，最后列表让我决定怎么做（ Windows 逻辑），而它只有闭着眼睛闷头干，或者每次都询问我，不允许对每个文件进行单独的决策。

套件分析：相册

我的父亲是一位很热爱生活的人，很多年前他买了一台相机，游山玩水的时候会记录很多照片，回到家分门别类整理好放在每一个文件夹里，从 2010 年一直带到现在，光看目录就知道当时去了哪，在干什么。

那么，把整理得这么细致的照片放到绿联相册里会是什么样的呢？?……

是的，绿联云在设计这个东西的时候一定是参考手机 OS 的 Gallery ，就是往一个叫做 DCIM 的文件夹里猛塞图片就好了。我从来没见过相册归纳软件竟然能完全抛弃子目录信息。我当然可以辛苦自己每个 subfolder 单独创建一个相册，但是人生的时间不是这么浪费的：

我的相册名必须低于 15 字，为什么？看看上面的文件夹有哪个 15 字写得完？
我必须从本机、存储空间、或者相册内部手动指定一张图片作为相册封面，在创建空相册时只能从本机照片指定，而不是根据相册内容自动创建封面
我不能从公共空间读取图片创建相册
我无法选择有限的成员开放相册共享，只有 0 和 1
我必须在相册 APP 里创建相册，与其它套件（说的就是你，文件管理）没有一丝一毫的联动
我必须先创建空相册，再双击进入到空相册内部才能添加图片
其实我说错了，当我在相册“收藏”一张图片时，他会以文件的形式出现在“文件管理”APP 左侧“我的收藏”里，但不会体现在“相册”里的任何一个地方

我发现一件事情，上面的第 2 点和“参考手机 OS 的 Gallery”交互理念是冲突的，手机 OS 的 Gallery 意图是让用户把图片全部丢进去就好，它去自动 AI 分析，省心，但是 UGOS 只省了一半，我还是得自己管理贴张图，是这个意思吗？

很难理解负责相册和 Explorer 的 UX （如有）在想什么，把图像和文件之间的管理搞得乱七八糟，而最关键所需的功能却见不到：

套件分析：云影院

实际上我自己长期以来在用的媒体库是 Jellyfin ，已经在 Jellyfin 搭建好了成型的接近 3TB 的庞大影视资源库。但问题在于，让完全不懂操作的家里人去弄端口登录，还额外下个 APP 也不现实，那就试试云影院好了。

（另外一个原因是，我的 Jellyfin 还提供一些同龄人看的东西，跟我的兄弟也好教、会折腾）

云影院更是一个重量级选手。它提供两种刮削源，一个内置的“智能识别”，以及 TMDB （ TheMovieDB ），让我们先来欣赏一下智能识别的准确率：

于此相比，同样的资源在 Jellyfin：

官方的智能识别源可谓是一塌糊涂。他犯下了一个质量差的刮削器能犯下的所有错误，比如说，把 Fate/Stay Night UBW 识别成了 Fate/Stay Night （近似错误）、把花絮和 Special 识别成了毫不相干的其它影视资源（随机错误）、把 Tenet.2020 识别成了册那 2020 （匹配错误）等。

而且在 PC 端，这个播放窗口竟然不能调整大小……只有 540P 小屏和全屏，并在在我的机器上（ 5900X+3090 ）部分视频源无论放什么视频都会在播放大概 2-3 秒之后停住不动，而拖动进度条却能继续播放，怀疑是播放器写得有问题，卡在了关键帧解码。至于字幕渲染质量什么的我也不好意思继续提，因为即使是与视频文件同名的字幕它都匹配不到，让我在文件夹里手动选……还是先把匹配做明白再去苛求质量吧。

然后你猜怎么着，这个云影院是有适配鼠标侧键前进后退的，然而文件管理却没有。

那我们把官方的“智能匹配”取消掉，使用 TheMovieDB 呢？当然没有问题，因为 Jellyfin 也将 TheMovieDB 作为数据源之一，能在 Jellyfin 正确识别的片源 90%以上都能单纯依靠 TheMovieDB 源识别成功。所以我建议原来在 Plex/Emby/Jellyfin 库迁移过来的朋友，使用纯 TheMovieDB 源。但我需要跟随官方一篇教程去花十来分钟注册 TheMovieDB 、申请 APIKEY 、测试解析配置 Hosts ，有一种传统互联网的美。

那如果我的老豆老母老姐老哥恰巧喜欢看外国电影、看美剧，而我自己不看怎么办？我还要一个个去教他们怎么去一个全英文的网站申请 API key 、测延迟选 Hosts 吗？

我想了想，也许这是我的问题。遵守国际源刮削规范的影片很明显在“智能匹配”识别率并不高，我在怀疑相比这样的名字：

Fast.and.Furious.F9.The.Fast.Saga.2021.DC.1080p.BluRay.x265-RARBG

是不是这种识别率更高呢？

速 d 与 j 情 9[1080P 蓝光超清][高清电影网]

既然云影院能够添加公共空间的视频，那么从这个云影院是公共的这件事也就合乎常理了。但是阿绿再一次选择了打破常规：我教我老姐如何使用 APP 的时候，惊奇地发现她的云影院是空的。我找了半天去哪里将片库设为公用，发现满屏幕只有“个人影院”，把个人影院四个字点烂了也只是一个筛选器在疯狂地伸缩，最后发现所谓的公共影院的功能叫做“一起看”，还是邀请制的，你分享一个片库需要被分享人同意……

就好像在一个悠闲的周末晚上我邀请大伙一起看电影，然后把片库分别发送到大家的手机上，电视放在那不开，大家点击自己的手机各看各的。并且经过实测，这个叫做“一起看”的功能完全没有类似异地放映室播放进度同步的机制，它只是单纯地把片源共享，有一些名不副实。产品经理知道什么叫做“一起”吗？

云影院的用户隔离机制无关技术问题，单纯是产品经理脑子出了问题，产品定义到这突然就混乱了，放着好好的公共/私人域不做，突然异想天开搞邀请分享制。

套件分析：云音乐/有声书

我相信这个东西应当不会有人用。不支持选择输出设备、不支持读取 FLAC 内置的 TAG（导致所有在 Foobar2000 分类整理好的歌单导进来全部变成文件名）、不支持导入公共空间资源、不支持 AIFF 、不支持 CUE ，道阻且长，绿联加油吧。

晚 22:00 更新：
它不是不支持读取 tag ，而是读得非常慢，晚上回来一看歌曲元数据慢慢都蹦出来了，怀疑在后台建库建索引，那么慢一定用的是 MySQL 。

套件分析：备份

我对 NAS 的另一个重要需求就是文件自动备份（和微信备份，但是这台 NAS 不支持），而且只要求备份不要求同步，因为我的主力机已经有 2TB+8TB 的空间。

我一般习惯把工作目录放在桌面，代码项目放在~/*Projects ，过一段时间后归档到硬盘中，现在有了绿联云 NAS 自动备份……

已经连续 4 天没有关机了。

PycharmProjects 文件夹总大小 101GB ，文件数量 536957 ，文件夹数量 66488 ，这套套件的 PC 端备份在遇到十万以上数量级时会出现严重的性能问题，以至于现在我 4 天没有关机，第一次全量备份的完成度还未达到一半。而且备份文件的速度会越来越慢，在连续运行十来个小时之后会停滞不前，“我的备份”窗口会直接无响应挂掉，必须退出绿联私有云客户端再重新启动，它才会以一个比较慢的速度继续运行备份。而且是每十几个小时需要重新启动一次，天知道我离第一次备份成功还有多远。

不过这种极限工况不是所有人都会遇到的，目前我的相册自动备份大概 3000 张，比较流畅，不会有什么问题。

套件分析：百度云

我自己是向来不用百度云盘的，从拥有自己的电脑开始，数据一直牢牢掌握在本地硬盘里，需要的资源也总能从云盘以外的地方找到替代品。

但是家里其他的年轻人会用。我在邀请他们加入私有云后，我说我不用百度云盘的，但是你可以登陆试试，把云盘上的东西下载到家里，本地化。然后她在她的手机点了一下百度云盘插件。

提示“仅限管理员使用”，她让我给她开下权限，这个时候我人已经麻了，因为我已经意识到百度网盘估计只有管理员能用这一事实。

所以现在我的账户上很无奈地登录着别人的网盘，挂着别人的下载，等到下载完之后还要操作移到公共空间给其他人取用（没错，百度网盘的保存位置，又不支持公共空间了）

我尝试理解这件事情，虽然不懂技术的人根本不会管为什么不能用。我推测这类第三方工具本身限制在一个系统里面运行多个实例，出于之前分析的用户机制，实例只能交给管理员用户运行。

那这种情况在不考虑法律风险的时候怎么解决呢？虚拟机或者容器化方案。这就是新的问题了：

现阶段绿联根本没把虚拟机做出来，在当前用户机制的约束下做出来的难度比拿正经 Linux 重构还大
假设我们使用容器来承载多个实例，并且对用户隐藏，可以做到吗？

答案是不完全可以。docker 是不支持隐藏 container 的，但是 docker 支持每个用户运行不同的dockerd，那系统镜像就交给 root 运行好了，其他用户以自己的身份管理自己的dockerd，方案很不错。

但是非管理员的用户在 Linux 不真实存在，并且现在套件里的 dockerd 就是以 root 身份运行，如果要更新，那么怎么处理 root 容器降权迁移的问题？

另外，dockerd 多用户机制依赖systemd，而 Openwrt 正是**不使用systemd**的一个 Linux 发行版，意味着多用户容器方案在当前架构下不可能实现。

下集预告

对这个奇葩系统的分析就此结束了。我们接下来将会基于这些分析的结论寻找解决方案，结合我踩坑的经验，告诉大家在这台机器上，想要部署一个普通的三方媒体库和下载插件需要经过哪些步骤，使用过程中又会遇到什么样的坑。

系统级部署 Tailscale 内网穿透
docker 容器间组网和配置
docker 公共空间的挂载方法
aria2c 镜像部署
qb 正确的配置方法
公网安全保护指南
Jellyfin Plugin 配置和个性化配置

附录

根据 Nginx Conf 生成的反代列表，传入数据不合规的时候会被 rewrite 跳转至 404“固件版本过低”页。

列表由 GPT 整理，因为上下文过长，GPT 遗忘机制导致可能会出现一定的错误，请自行前往/etc/nginx比对甄别

# Generated by ChatGPT
LISTEN 9999 [::]:9999# NAS server
/                                 -> :9996# Ugreen launcher
/home                             -> /data/app/com.ugreen.ugos.launcher/www/index.html

# Docker Hub API
/docker/image/search              -> https://hub.docker.com/api/content/v1/products/search/# Core server
/v1/user/login                    -> :9994# Album server
/v1/album_svr/                    -> :9982/v1/ai/album/                     -> :9982/v3/ai/album/                     -> :9982/v1/album/manage/                 -> :9982/v2/album/group/                  -> :9982/v3/cloud/album/                  -> :9982/v1/ai/task/                      -> :9982/v1/ai/scan/                      -> :9982/v1/ai/similar/                   -> :9982/v1/ai/blur/                      -> :9982/v1/ai/face/                      -> :9982/v1/ai/file/                      -> :9982/v1/album/people/                 -> :9982/v1/tidy/                         -> :9982/v1/myself/del_myself_folder      -> :9982# Baidu Pan server
/v1/baidu/rest/2.0/xpan/          -> https://pan.baidu.com/rest/2.0/xpan//v2/baidu/oauth/token             -> https://pan.baidu.com/rest/2.0/xpan/# MiniApp Yun server
/v3/cmcc/devapp/                  -> https://miniapp.yun.139.com/richlifeApp/devapp//v3/cmcc/open-mpplatform/oauth2/  -> https://miniapp.yun.139.com/open-mpplatform/oauth2/# Docker web
/docker/web                       -> /ugreen/docker/www

# TTYD server
/ttyd                             -> :DYNAMIC

# Docker images export
/docker/images/export/            -> :9375# Docker image search
/docker/image/search              -> https://hub.docker.com/api/content/v1/products/search/# Docker image repositories
/docker/image/repositories/       -> https://registry.hub.docker.com/v2/repositories/# External backup server
/v1/file/external_backup/         -> :9984# Favorites server
/v1/favorites/set                 -> :11024/v1/favorites/get                 -> :11024/v1/favorites/cancel              -> :11024# File collect server
/ugos/v1/file_collect/            -> :12028# File share server
/v1/share/get_shared_files_of_users -> :11025/v1/share/get_users_of_share_file   -> :11025/v1/share/share_files               -> :11025/v1/share/cancel_shared_files       -> :11025/v1/share/get_all_users             -> :11025/ugos/fileshare/v1/shared_user/list -> :11025# File search server
/ugos/globalsearch/v1/            -> :12029# IPC server
/v1/task/                         -> :9992/v1/baidu/                        -> :9992/v1/transcode/                    -> :1080/v1/disk/                         -> :9992/v1/storage/                      -> :9992/v2/storage/                      -> :9992/v1/stormng/                      -> :9992/v1/dl/                           -> :9992/v1/cmcc/                         -> :9992/v3/cmcc/                         -> :9992/v1/file/storages                 -> :9992/v1/file/disks                    -> :9992/v1/category/                     -> :9992/v2/category/                     -> :9992/v3/category/                     -> :9992/v3/storage/                      -> :9992/v4/storage/                      -> :9992/v5/storage/                      -> :9992# LBook server
/ugos/lbook/v1/                   -> :11029# Log Center server
/ugos/log_center/v1/              -> :10002# Media Player server
/v1/mediaplayer/                  -> :1085# Movies server
/v1/movies/                       -> :9980/v2/movies/                       -> :9980/v3/movies/                       -> :9980# Music server
/ugos/music/v1/                   -> :11028# Service Manager server
/ugos/service_mgr_svr/v1/         -> :19010# Thunder server
/device/info/watch                -> :5050/device/now                       -> :5050/device/authlogin                 -> :5050/device/v1/                       -> :5050# Thunder web
/web/thunder/                     -> :5050# Transcode server
/v1/transcode/online/                   -> :1080/v1/transcode/online/info/              -> :1080/v1/transcode/online/                   -> :1080/v1/transcode/online/status             -> :1080/v1/transcode/online/switch_resolution/ -> :1080# Data app
/data/app/                        -> /

# App
/app/                             -> :9999# User Management server
/v1/quota/project                 -> unix:/var/run/user_manage.sock
/v1/quota/user                    -> unix:/var/run/user_manage.sock
/v1/quota/volume                  -> unix:/var/run/user_manage.sock
/v1/timemachine/query             -> unix:/var/run/user_manage.sock
/v1/timemachine/set               -> unix:/var/run/user_manage.sock
/v1/cache/write                   -> unix:/var/run/user_manage.sock
/v1/cache/remove                  -> unix:/var/run/user_manage.sock
/v1/cache/clean                   -> unix:/var/run/user_manage.sock
/v1/cache/query                   -> unix:/var/run/user_manage.sock
/v1/localuser/list                -> unix:/var/run/user_manage.sock
/v1/localuser/exists              -> unix:/var/run/user_manage.sock
/v1/localuser/create              -> unix:/var/run/user_manage.sock
/v1/localuser/modify              -> unix:/var/run/user_manage.sock
/v1/localuser/delete              -> unix:/var/run/user_manage.sock

# WPS server
/v1/wps_doc/                      -> :11027

深入解析绿联云 DX4600 Pro UGOS 系统(1)

Wed, 31 Jan 2024 13:02:35 +0800

感谢与感想

在开始之前我想要着重、着重感谢一下绿联私有 DH2600 、DX4600 、DX4600+这些产品的老前辈用户。我到手的时候固件已经是最新的 v4.7.0 ，我这两个星期的体验后，实在很难想象这些老用户们早期系统是如何坚持下来的，是他们在一无所有的时期对绿联的支持与付出才让它发展到如今这个勉强可用的系统，并且仍旧有非常多的问题，这些老用户的地位堪比华为寒意传递时期还愿意掏 7999 买 P50 、P60 的铁血花粉，Respect ！

如果绿联私有云团队真的会在各大社区听取用户意见的话，那他们看完这篇文章我应该会被封号吧？

绿联的宣发口径其实非常鸡贼，到现在他们依旧把自己的产品线称作“私有云”而非“NAS”，它的产品定位和体系确实和传统意义上的 NAS 有所不同。具体来讲：

这个东西放在我的家里，我家有 4 口人，各自使用 DX4600 Pro 的感觉就像是 4 个合租在一起的陌生人一样。每个人手机上都登录着自己的“XX 云网盘”，管理自己的数据，只是他们恰好都存在这台 DX4600 Pro 里面罢了。

SSH

从我在网上搜集到的资料来看，这台 NAS 的 SSH 权限大概经历了 3 个阶段，一开始是 Docker 提权，然后是网页端请求抓包，现在 v4.7.0 版本的固件已经完全开放了 SSH 功能，仅需要管理员打开设备管理-调试功能，验证短信之后会生成一个临时有效期 3 天的密码，依靠这个密码直接登录到 NAS 的 922 端口即可，用户是 root 。

至于 SSH 工具什么的不需要再教，VSCode 、Xshell 、Tabby 等软件随处可见。

来自绿联云技术支持的温馨提示
您好，目前最新固件已支持用户开启调试服务哟，但是绿联私有云系统是在特定的环境和配置下进行测试，如果贸然进行底层系统的修改会破坏系统完整性，从而导致系统运行不稳定和其他不可预测的结果。
温馨提示：
①不建议个人进行 SSH 的操作，由于个人操作导致的异常，绿联私有云无法提供技术服务； ②由于个人 SSH 操作导致的异常问题，类似系统崩溃/宕机，需要自行支付费用进行售后维修。

OS

在购买之前我已经有所耳闻，这个逆天的 UGOS NAS 系统用的是 OpenWrt ，一个面向嵌入式设备的残核 Linux 。配套 shell 是 Busybox+ash ，Debian 系的相当多工具和内核功能在这是没有的，比如 sudo 、getent 、file ，尤其是 systemd 。

不过在我看来，使用 OpenWrt 有可能唯一的好处是，这台机器背面是有 Reset 键的，除非手贱折腾引导，那么系统绝大部分时候人为弄出的错误可以通过长按 Reset 键进行 Hard Reset 恢复出厂解决。在我使用这台机器的两个星期里，就有一次因为我不小心打了不兼容的 kernel mod 导致系统崩溃，机器都开不起来，官方在网站上根本没有提供任何固件包，最后通过长按 Reset 重置系统救了回来。

OPKG

既然用的是 OpenWrt ，那么必然就会有 opkg 包管理器。UGOS 的 OpenWrt 是自编译系统和内核，因此只挂载了 Snapshot 源，通过 opkg 安装的绝大多数包都会因为内核 fingerprint 不匹配导致安装中断，需要使用--force-depends 参数强制安装。

当然，我们可以编辑/etc/opkg/distfeeds.conf 添加源，但是源的软件兼容性有一些问题。通过外部引入packages-22.03源安装的所有包都无法执行释放到/usr/*bin 下的二进制可执行文件，会提示Not found/No such file or directory。

这个问题我花了大概 3 天的时间尝试去弄明白为什么，最后在 V2EX 论坛一位叫做 listenerri 的用户在其它 Linux 开发的帖子里提到了关键点：

安装下来的二进制可执行文件在系统目录里是真实存在的，使用 which 语句也能精确定位到可执行文件的信息。那么出了问题的就不是程序本身，而是程序的依赖。我们通过strace跟踪运行程序时的调用堆栈，ldd检查程序运行依赖库，结果会发现所有自行安装的程序都以错误ENOENT退出，ldd检查得知所有自行安装但无法运行的程序都缺少一个库：libc.so

libc 是 Linux 系统最基础的 C 运行库，是个正常的系统都应当编译时就携带。我一开始以为是我之前弄炸内核强行 reset 系统导致的意外丢失，跑去问技术支持，得到的答复是，他们的系统镜像“编译时就没有这个库”。

我们可以通过以下命令进行验证：

ll /lib/libc*								# Overlay 级别/lib 搜索find / -name "libc*" ! -path /mnt/dm-0/		# 全盘搜索，硬盘区除外find /rom -name "libc*"						# 系统镜像层搜索

然后会发现真的没有。

根据 listenerri 的说法，在 Genaral x86_64 Linux 系统里，

一般情况下 Linux 系统具体小版本的 so 库文件都是未带版本号的 so 库文件的原始文件
执行如下命令创建 libc.so.6 到 libc.so 的符号链接：
cd /lib/
ln -sf libc.so.6 libc.so
按说是立即生效，不行就重启试试

对 Openwrt 是无效的。Openwrt 是一个面向路由器等低容量 ROM 低功耗设备的 Linux 分支，它的很多系统机制都是以牺牲通用性为前提尽量地降低系统的资源占用，包括包管理：绝大多数在 opkg 发行的应用程序会把所有的底层库抽掉，进而使用系统环境提供的动态链接库，以节省空间，所以系统一旦库出现问题会导致大面积的程序失控。

libc.so作为最底层最基础的库，对于用惯了 x86 计算机的我们来说，从同 CPU 甚至是同 CPU 架构的系统中直接 copy 一个过来也能用是很符合直觉的，因此我就这个问题去 Openwrt 论坛问了一下，核心开发者给我的解答如此：

libc.so 对 x86_64 的 Openwrt 设备是通用的吗？
不是的，尤其是在涉及供应商提供的固件时（他们似乎选择了非默认的 glibc 构建，而不是 OpenWrt 默认使用 musl ）。即使在不同版本的 OpenWrt 之间也不存在二进制包的兼容性（更别提 libc ），当涉及到第三方或私有构建时，所有的可能性都不存在。

没戏。我们想要安装一些软件时，最好期望它在别的 release 渠道有面向 General Linux System 的二进制包，因为他们大多数都内部集成了所有的运行库，不需要依赖操作系统提供，否则寄希望于 opkg 什么都跑不起来。

物理存储, xfs, raid

坦白来讲，我在网上早期了解的时候发现 DX4600 （非 Pro 版）用的是 ext4 文件系统，当时已经萌生了如果到手发现还是 ext4 我就退货换 QNAP 的念头。但是好在到手查阅了 4600Pro 的说明书后发现这台新机器已经用上了 XFS 文件系统，不奢求这类新派 NAS 厂商玩得明白 Btrfs 和 ZFS ，XFS 相比 ext4 已经好很多，还算是能够接受。

UGOS 目前在创建阵列的时候不支持指定文件系统，支持的 raid 有 0, 1, 5, 10 ，并且在创建好 Raid 后会立马进行全盘校验。我自己买了 4 块希捷 X18 16TB ，代表做好存储空间后，系统会全盘满速读整整 1 天时间，在这期间基本上干不了任何事情。

通过 parted print all 能够看到，这台 NAS 的系统数据存在一颗三星 BJTD4R 的 EMMC 上，容量 32GB ，分区格式 ext4 ，一旦搞坏 boot 是真的要返厂的，魔改党建议尽量别碰 boot 相关的东西。同时，EMMC 使用的是 Openwrt 特有的 ROM+Overlay 机制，除非闪存出现了物理级的错误，无论对系统进行什么改动都伤不到原厂的镜像分区（ mmcblk0p4, mounted at /rom ），把 Overlay 层一清空又是崭新出厂

建立好存储区后查询得到的 Raid 信息：

值得一提的是，我创建这个存储空间时漫长的 CC （一致性校验）进行到 48%左右系统被我玩崩溃了，不得不重置。重置结束后存储空间依旧能够使用。我询问技术支持，说这种情况还要继续校验吗？技术支持说要的。我问入口在哪里？他说没有入口，系统会每 3 天自动执行。但是截至目前 NAS 已经跑 7 天了，我依旧没有见到系统有任何准备做/在做 CC 的痕迹。

网络服务，SMB

这台机器和真正”生产力“有关的所有东西都在一个叫”网络服务“的应用下，你可以操作开启 SMB 、AFP 、FTP 、WebDAV 和本地帐号登录，那么考虑到因为 AFP 和 FTP 已经是过时的网络协议，四舍五入这台 NAS 只支持 2 种主流网络协议，不支持最专业的 iSCSI 。

并且其中有一个很奇怪的点是，想要开启任意一个网络服务，管理员必须，必须建立一个”账号“，并且这个账号与什么登录绿联云的手机号是无关的，从属于管理员名下，使用的是管理员的存储空间。

同时，这个”账号“修改密码必须要输入旧密码，一旦忘记密码就没办法修改，但是可以直接通过”修改账号“建立一个新的（甚至是同名的）账号强行把忘记密码的旧帐号顶掉（伏笔，后面会知道原因）

SMB 服务是我对这台 NAS 系统了解的突破口。我就是依靠 SMB 的配置文件定位到了文件与物理硬盘之间的对应关系。通过cat /etc/samba/smb.conf获得：

在这里，SMB 开放的路径就是 UGOS 对应的存储空间，并且仅授权给我们创建的”账号“使用。同时，UGOS 依靠 smb4 提供了删除文件的回收能力，删除的文件会被移动到一个中文的隐藏文件夹中。

（重要） NFSd

我们都知道，SMB 在传输速度高于 2.5Gbps 后对 CPU 的资源消耗显著，速度达到 10Gbps 后多数普通家用 CPU 无法承担。与此相比，NFS 通过直接寻址的方式提供文件传输，大幅度降低 CPU 开销和延迟，是下一代的网络文件传输协议，对于工作室和重度生产力用户而言是最强大的 NAS 协议选择。

NFS 在 Linux 已经普及，Windows 平台在 Pro 以上 1607 版本以后原生支持 NFS Client ，需要在”启用或关闭 Windows 功能“中手动开启。

我在购买这台 NAS 之前曾经广泛地搜索了相关的软文和评测，所有的文章都提到这台东西支持 NFS ，放心买回来才发现事情有坑：

这台机器只支持做 NFS Client 端，即挂载其它 NFS 网络位置，但是并不支持 NFS Server！

经过深入的调查发现，UGOS 系统已经安装好了 NFS 相关所有的 kernel mod 、驱动、服务以支持 NFS Client 运行，但是唯独把[内核]nfsd、[服务]nfs-kernel-server、[内核模块]kmod-fs-nfsd抠掉了，说明他们是故意屏蔽了 nfsd 功能，具体原因我问客服只得到”不方便透露“的解答。

所以我就想自己尝试把kmod-fs-nfsd打上去然后安装nfs-kernel-server。由于 UGOS 编译选用了 Snapshot 路线，22.03 版本的 snapshot kernel 已经刷到了 150 多。查询本机得知，kernel 版本为5.10.120-1-fa9766b60e358499f4a6b9ef8f360e07，即使他们使用官方内核，snapshot 编译记录也早已被删除。

因此，本着”反正大家都是 x86 ，兼容性强得很，直接强打内核补丁试试“的想法，我去找了个内核版本近似的 release （具体来说，是22.03.0-rc4，内核版本5.10.120-1-3136c8a0893fac7c59d0a669ad504887），下载kmod-fs-nfsd的包，然后通过篡改内核 hash 的方式用 opkg 强制安装……

结果，系统当即就炸了，所有东西全部宕机无响应，蜂鸣器报警，重启发现根本开不了机，HDMI 无输出。本来我已经做好了送回厂家刷机的决心，结果看 PC 端的提示才发现这机器有 Reset 键，照着说明拿卡针捅到重启，还真复活了。

那怎么办呢，手动安装 nfsd 的想法就此作罢，现阶段只能等官方更新了。论坛的建议区几百条帖子鲜有官方的人回答，并且据消息说官方在年底的任务是用 Debian 重构 UGOS 系统……我能信吗？

P2Px

我对绿联云一直宣传的自动 P2P 内网穿透方案很感兴趣。不是因为它是什么新鲜事物，而是因为它是第一个大规模宣传自己穿透是基于 P2P 而非中转的（也有可能某个竞争对手的宣发预算不够，没传到我的微博信息流里）。作为一个 ZeroTier 和 Tailscale 的重度使用者，深知 P2P 打洞这个事情在当前公网环境下的重要性，以及对普通用户而言的驱动力——让他们享受 P2P 的成果是很乐意的，但是一旦要操作一些他们不认识的工具，即使是 Tailscale 这种简单到只要安装客户端再登陆一下并且保持开启的软件，普通用户就不乐意了。

绿联私有云客户端的连接和穿透仅限 APP 内，但是不需要打开任何的∨PN ，直接连接，看看库存影片什么的已经足够方便。根据实地测试，绿联云内置的远程穿透能力尚可（至少在同一个城市里，跨 IPC 以及多层 NAT 内网并不是什么问题），但是穿透的速度非常慢。多数时候可能要等待 1 到 2 分钟才能够远程连接到家里的 NAS 。有这个时间换 Tailscale 东西已经下载好了。

在 NAS 帮助教程里日志中心的文章有句话特别有意思，说127.0.0.1是来自于 P2P 的连接，说明 UGNAS 的 P2P 方案应当不是类似上面两位那种基于 Tun 虚拟组网隧道的。

在一次查进程的时候偶然注意到运行的进程中有一个名为 p2px 的进程，来自于/data/nas_server 文件夹——这是 UGOS 服务模块存放的地方，所以我基本上锁定这个模块用于负责内网穿透：

这个进程运行的时候甚至会上报本机的 SN ，于是围绕 P2P 进行全盘搜索，能够找到 p2px 的配置文件、日志、相关依赖和二进制可执行文件：

p2px 组件使用了libmosquitto库，这是一个 eclipse 开源的 mqtt broker ，推测是拿 MQTT 用于 STUN 。同时，在 conf 文件夹中找到了关于 p2pTunnel 的若干配置文件，显示其会指向ugreengroup.com域名，与我在 QX 的网络活动观察到的结果一致：

配置文件中的 AccountCode 直接揭晓了答案，使用了 pptun 的方案，顺藤摸瓜搜过去，是一家名为深圳穿透科技的公司的产品，这家公司从头到尾只做一件事，就是搞 P2P 穿透的各种生态。其中 pptun 是 PaaS 级别的，也提供 SDK 二开和自部署。

通过查询 p2px 的日志，穿透信息确实由该公司的pgLibTunnel和pgLibConnect提供，至于这个ugreengroup.com域名是绿联自部署还是直接解析到 pptun 的 PaaS 就不得而知了，但很大概率是直接用了 pptun 的服务。

我推测这台 NAS 的内网穿透是以设备 SN 作为唯一标识符的，客户端的连接请求在 MQTT 队列中传播，MQTT 充当 STUN ，p2px 则监听面向自己 SN 的连接请求，交换 IP 信息和信令，直到双方逐步穿透成功，连接设备。pptun 即使穿透失败也能够用 Tunnel 中转维持连接，但是我怀疑，连接耗时 1-2 分钟的原因是，APP 直到能够成功建立 P2P 连接才允许进入主页，而在这个过程当中中转隧道已经早就建立好了，但毕竟服务器跑中转流量还是耗钱嘛，所以不让在中转模式下使用。

（以上内容只是推测，不代表真实情况，因为我也没有去抓包分析）

这部分知识我是通过 Tailscale 团队的一篇文章《 NAT 穿透是如何工作的：技术原理及企业级实践》学习到的，真的很有意思，我很推荐大家都去读一读。

目录窥探

我通过 SMB 的配置文件获取到了存储空间的物理目录，进而能够一探究竟：

存储空间下的所有文件都存放在 raid 阵列中名为.ugreen_nas 的隐藏文件夹，并且划分了好几个区域。我认为掌握了这些信息，即使在 NAS 机体损坏的情况下，我们也依旧有希望能够取出硬盘中的数据。经过我的测试，这些文件夹大概的作用如下：

6 位数数字的文件夹是每个用户自己的存储空间
1 是公共空间
2 暂时未知，应该是某个服务，我目前还未使用过”共享空间“，可能是它
3 是回收站
6 是 docker 数据区域
7 是 hls cache ，怀疑与云影院/在线播放器有关
ai_sevr 存储相册的人脸识别数据
album_sevr 存储相册其它信息，包括索引、元数据等
category_sevr 存储用户名下文件分类数据，就是”文件管理“中左侧分类查看“图片、视频、文档、压缩包……”的索引
data/data 存储 nas 套件部分服务数据，比如说全局搜索、日志中心、云音乐、壁纸，并且按用户分文件夹存储好

（非常重要）权限模式与用户隔离

UGOS 的权限模式非常的奇葩，我在一个正常的 Linux 系统上从来没有见过这样的用法，并且这个系统软件的很多功能缺陷都是由权限模式导致的。

我把 UGOS 面向用户的服务套件叫做nas_server，暂且把它当作一个 service 级别的东西，那么我们有以下几个结论：

套件的所有用户事务（登录、权限管理、软件数据隔离、存储区区分等）全部交由 nas_server 托管，与 Linux 系统的 user-group 机制脱钩
nas_server 自始至终在 UGOS 中以 root 身份运行
每个登录到绿联私有云 APP 、并且连接到某台 NAS 上面的用户，会被 nas_server 单独分配一个用户 uid 数字，nas_server 依据此数字来管理用户对应的物理存储、维护用户私有数据，并且这个 uid 对用户不可见
（注意，这里说的 uid 和 Linux user 的 userid 没有任何关系，我们后续会将这个 id 称为ug_uid）
nas_server 在文件管理时，只负责目录级别的可见性，不会负责 rwx 权限。严格来说，整个系统都没有对 rwx 做任何管理，默认都是 777 。
目录级别的可见性，指的是它只会把你用户在/mnt/dm-0 存储空间中对应的文件夹单独展示出来，而不管文件夹中是否有任何权限不对、owner 不匹配的内容
nas_server 对文件的错误权限有恢复机制，当用户尝试通过套件访问存储空间里不属于它/权限不足的文件时，文件的权限会被强行修改为 root 777
测试样例：root 登录 ssh 创建一个文本文件，将其 owner 修改为某个别的用户，权限修改为 755 ，移动到某个共享成员的存储空间内。成员通过套件内置的金山 WPS 打开文本后在 ssh 窗口 ls -l ，会发现文件被重置为 root 777

（重要）为什么只有管理员能开 SMB ？

这个问题是从我邀请家庭成员进入 nas 后探索目录时发现的。一开始我以为 nas_server 管理/mnt/dm-0 是简单地把所有文件都设为 root777 ，却惊奇地发现好像其他成员的文件夹 owner 并不一样，他们与文件夹同名，对应一串长长的数字，具体而言是ug_uid+0000。凭借着我对 Linux 浅薄的经验，去/etc/passwd ，以及其他地方找了很久都没有找到 username ，经过了大量的实验和思考之后我认识到了一件事情：

只有管理员开设的“网络服务”中的“账户”在 Linux 下是真实存在的，其它用户在 Linux 系统中不存在！

当你开通网络服务的账户后，你自己的 ug_uid 才在 Linux 系统下有真正的实体 user 对应，uid 和其他用户一样，都是ug_uid+0000，而包括 SMB 在内的大量功能，需要依赖 Linux 的实体用户运行。因此，只有管理员能够开设 SMB ，并且出于隐私原因 SMB 也只能提供管理员的私人空间和公共空间。幸亏我家四口确实只有我在用 SMB ，多一个有需求的人，立马就要退货。

所有想要折腾绿联 NAS 的人都必须记住这个结论，这个结论可以解释后面非常多不合理的地方。

nas_server 会自动将其它用户创建的文件 owner 设置成一个**没有实体用户对应的ug_uid+0000**，以区分存储区 owner ，因为 Linux 系统是可以强制用 id 数字指派文件 owner 的。然而对文件指派 owner 似乎没有任何用处，可能是给内部其它服务进行区分，因为上面提到了，“文件管理”APP 只根据目录提供内容，根本不管 owner 是谁，错了就重置成 root 777 。

这套容错机制可以保证用户通过套件使用绿联私有云的时候不会出现奇怪的权限问题，但是对于 SMB 等严格遵守 Linux 用户权限规范的服务来说并非如此。举个例子，我现在使用 root 在自己的存储空间里创建了一个文本并填充了内容，将其权限改写成 755 ，通过 SMB 访问文件，修改并保存，会发现没有保存权限，记事本弹出“另存为”窗口。

这种情况会更多出现在某些 docker 镜像中，他们支持通过 PGID 和 PUID 环境变量指定 bind volume 产生文件的用户映射，并且假设默认的 permission mask 是 022 的话，产生的数据和配置文件通过“网络账户”登录的 SMB 是没有修改权限（ 755 ）的。

很显然，这套权限模式经不起系统级的全面开放访问，所以聪明的绿联产品经理想出了一个解决方案，那就是：

禁止非管理员使用 docker 和 smb 就好了，再在 docker 镜像管理页面里加上一条免责声明，出了问题不怪我哦。

Nginx

在 UGOS ，每个服务组件都有自己要忙的事，他们对外提供了各自的服务端口供套件内部分别访问。所以他们写了一个极其、极其、极其冗长的 Nginx 配置文件，把所有 web 地址、端口、socket 、url 跳转聚合起来，反向代理到自己的 web 登陆端口（也就 9999 ），活生生用 Nginx 写出了一个 API Gateway 。

可以理解，把所有端口聚合在一起方便内部服务统一调用，避免访问自己东西的时候配置端口东一个西一个，而且内网穿透用的 P2Px 程序可能也难远程实现多端口访问。

问题是，这些套件（除了迅雷和百度云等第三方）怎么全都在监听0.0.0.0而非localhost呢？而且我在iptables和/etc/config/firewall也没看到拦截来自外网对这些服务端口的请求，猛地一看这些端口好像还是能公网访问是怎么回事呢？一旦有心之人掌握了服务组件的接口格式，他们是不是能够直接跳过 9999 端口的 Auth Header 校验，往我的设备发 reset 请求？我不是在渲染焦虑，而是连我这种曾经把自己机器放到 DMZ 公网上被打了 2 个 T 流量的、对网络安全毫无概念的人都感觉这样的处理方式有安全隐患，需要一个确认。

另外，用户远程访问 web 端 9999 ，所有的静态资源都被标记为no-cache, no-store禁止缓存，导致用户每次刷新和访问都要从上行速率本就不高的家宽从头加载你那些 js 库和媒体，这又是何意啊？