补充一点，咪咕世界杯 4K50hz 的 HDR 的码率大概在 20mbps 上下浮动 看具体的场景， 一些全场远景 15 左右，YUV420 ，就比赛时的 4K 投屏时强制 HEVC ，APP 设置里面的投屏设置无效的

咪咕移动端，DLNA 抓流可以确定咪咕输出的是 4K50hz 的 HDR 流，之前 22-23 赛季的时候有比赛虽然投屏显示是 4K ，但我 DLNA 抓出来是 1080P 的情况，这几年没遇到过了，但是央视给到咪咕的原始流是不是 4K 的就不清楚了。
今天中午的澳大利亚打土耳其，前面有一段时间咪咕自己的主舞台信号有问题就直接强制 CCTV5 了。

@dhc90 #6 是的，技术仲裁，我遇到的这种场景一般都是一些非常临时性的微信群聊，因为当有一方不懂技术的时候真的难受，例如今天这个对方怀疑我们这有问题后申请远控我电脑后，在我电脑操作那个服务的后台的时候，因为到对方不通他竟然是用我的电脑去 ping 我们的服务器 IP 而不是用服务器去尝试抓包他们的服务。

有没有这种场景：那种和人对接时，对方的人并不懂技术然后乱说乱传达，此时此刻我正在和对方的人对线，很急。

ID:3418 谢谢老板

兽人永不为奴

@yangg 套件是 Leobog 的 Hi75c Pro ，自己换了 FR4 的定位板，轴使用的雪碧 V2 ，键帽的 KOA 高度的冻酸奶，都是淘宝上可以直接买的。Leobog 有出官方成品 hi75 ，套件的底壳有开槽，自己换更大的电池会比成品麻烦一点点。

@stinkytofux 嗯，现在传统的 104 的键盘不多了，你可以看看 98 或者 100 保留了数字键，砍了部分 HOME 等功能键。

@yty2012g 嗯，我把之前的 pok3r 换了，换个 Hi75c+FR4 定位板+雪碧轴 V2 ，老键盘虽然没坏，但是也差不多该换了

@coderth 前几天的 demo 我玩了一下，作为一个从来没玩过的魂 like 的人，新手村就打好久，特别是新手村 1 打完 BOSS 让我跳入井里时，我引了怪，那个怪也追进井里的时候，绝望感完全包住了我，赶紧往尽头跑，结果到了尽头让我打一个一看就更 NB 的 BOSS ，感觉更绝望了，还好是剧情杀不用打。😂

玩的游戏当中，时间最多的应该就是魔兽世界,虽然机制老旧，问题多，但是用户黏度确实高。
独立游戏 ED ，基本上玩 4-5h 就丢了，上一个玩通主线的游戏还是刺客信条奥德赛（ DLC 没玩）。

可能我更喜欢玩网游吧。

我的需求和你的类似 但是有点不一样。
我本地的设备是 4K 200% 但是 RDP 的需要在 1080P 100%，即远端一直保持在 1080P 100%。
软件我用的 https://github.com/1Remote/1Remote ，
设置是这样的
https://i.imgur.com/tsg60cl.png
这种情况下，默认本地窗口与对端的分辨率为 1920x1080 ，并且无论本地的窗口无论怎么放大缩小都不会影响对端的分辨率。虽然这个时候点击窗口最大化，窗口大小也只会是 1920*1080 ，但是可以手动把窗口拉大，拉到几乎和本地显示器分辨率差不多后，在窗口标题栏右键-全屏 就可以获得 本地 4K200%下的全屏 但是对端还是 1080P 100%的画面，缺点就是会是糊的，毕竟相当于把 1080P 的图片强行拉伸到 4K 。

其实我这套方案用 mstsc 的参数应该就可以实现，但是 1Remote 用习惯了

现在存储高价，如果你不是刚需就别买了，如果你是真的刚需就直接现在买，未来存储涨跌没人能保证，拖着刚需耽搁难受的也是你自己。

N100 作为存储使用完全够用，我自己的 NAS 还是 J4125+8G ，不过我不是 All in Boom ，计算和网络我有独立的设备在跑，J4125 只跑存储对我来说完全够用了，CPU 发热低直接被动散热，只需要对硬盘散热，楼上提到的转码效率，如果你需要转码那么也记得考虑进去。

@fibroblast #5 建议这几天即便不关机，也最好关闭公网的访问，这段时间安全圈都在研究飞牛，已经有朋友给厂家发邮件了，漏洞不止流传的那俩个。

@libregratis #4 并不是所有能自己装飞牛的都小白，我身边就有啥也不会按照小红书和 B 站自己装飞牛的，飞牛论坛也有利用 AI 来查杀这次 0DAY 直接把系统搞崩溃的，他们可以按照教程搭出来东西，但是他们不会去看具体的代码，之前有朋友问我要实现某个设置要怎样，我给他说了思路后对方直接就是一句“你能不能把代码直接发出来我复制就完了”，他们真的敢执行 rm -rf ，所以我有想有没有一个对他们友好的方案去保护自己。

一觉醒来，看到飞牛发公告了，但是这个公告真的很想让人说两句，不知道飞牛的公关团队或者技术人员能不能看到这个贴，但社区的声音真的很重要。

昨天我在其他帖子说了希望飞牛能尽快正面、正确的面对，能发重要公告去告知用户去升级，现在飞牛发了，让用户升级，让用户开启更加严格的安全策略。但飞牛公司你们作为一个软件驱动公司还是有好多东西没有正面的面对。

1.已经被挂马的用户：
如何让用户确定自己被挂马、对于被挂马的用户如何去清除木马？升级系统 不等于 清除木马，后面有小白用户升级到 1.1.18 ，但他之前已经被挂，他依旧会去论坛发帖求助，甚至有可能说出“1.1.18 并没有解决我的问题”这种话。

2.公网访问：
请问你这个公网访问包不包括“FN connect”，如果你的公网访问指的是用户的主机有 V4/V6 的公网直接访问，不含你的“FN connect”，那么请问那些没开 V4/V6 公网但是开了 FN connect 的用户怎么办？他们会不会理解成我只开了 FN connect 那公告里提到的安全访问方式与我无关？飞牛厂家明明知道这次 0day 包括 FN connect 也中招了，为何避而不谈？至少今天凌晨我还通过贵厂的 5ddd.com 能发现大量有洞的设备。FN connect 有白嫖用户也有付费用户，这次 0day 中招的用户中，对于没有公网 IP ，但是是 FN connect 的付费用户的怎么去赔付？

有洞正常，有洞不可怕，可怕的是在 1.1.15 的 updatelog 不写修复的洞。可怕的是当技术团本发现问题了虽不能马上修复这个漏洞，但竟然不发叫用户关闭公网、关闭 FN connect 的缓解方案。可怕的是“
社区热点问题处理进展 20260130”里面没有任何关于 0day 的正面回应。

请做好一个 NAS 该做的事，安全。

@a9htdkbv #61 感谢，如果是 1 月 22 日的版本发布已经修复，那我纠正我的说法，用户需要尽快更新到 1.1.15 ，而那些已经是 1.1.15 但之前被挂马的机器，是需要官方技术团本去帮用户解决木马的，毕竟用户使用你家的存储产品但因为漏洞而被入侵，这是你一个软件驱动的公司应该做的，大量的用户其实是没有能力手动清除那些马的，是需要官方出一个清除方案/专杀工具的。

不过也论证了一个事情，飞牛公司知晓自己的产品存在高危漏洞的情况下，不仅没有发出非常明显的公告让用户尽快升级，甚至还在修复版本的 updatlog 里不写这个漏洞，给人一种我不说就无人知晓的感觉。希望飞牛在黑客进行大规模数据劫持行为前能够正面、正确的面对这个事，对用户负责。

@lyz2754509784 #45 我搜了一下 1.1.15 发布时间是 1 月 22 日，updatelog 里没有提到修复这个 0day ，无论是飞牛轮胎还是一些社群网站如 nodeseek ，在本周内都有提到飞牛攻击的事，可以 Google 就出来的，包括昨晚凌晨我刷飞牛论坛也有人提到自己的 1.1.15 ，但是也出现 CPU 高占用/有大量连接/大流量等情况，并且现在社区的维护人员也提到让用户查询是否大量下载/上传任务，在 0day 贴里也有人提高到 dockermgr
https://i.imgur.com/VvadNde.png
https://i.imgur.com/RjqFgj7.png
https://i.imgur.com/0oZg6YX.png
https://i.imgur.com/4hCbJrF.png
https://i.imgur.com/7QLg2zi.png
https://i.imgur.com/UuQyp7w.png

这些图全是我截图的 里面部分时间为相对时间。

不同的用户技术水平不一样，不是所有人都有 OP 这种能力判断自己被当作肉鸡，能发现自己 CPU 负载异常/大量连接/流量大少之又少，所以如果我们把那些最近系统组件大范围停止工作、流量异常、CPU 负载的用户都认为是被 0day 攻击的话，那么至少可以得出 1 月 22 日发布的 1.1.15 是没有解决用户被肉鸡这个事，飞牛是否有推出新的小的修订号来修正 0day 目前不清楚，但是用一个“1.1.15 已修复”的说法是非常模糊的，甚至带有误导性，让有运行着 1 月 22 日版本的用户觉得是自己安全的。

目前社区看下来普遍还是当肉鸡，没有提到被劫持数据的案例，飞牛我印象中是没有磁盘加密功能的了，如果出些大面积的数据劫持那么这次 0day 对飞牛的打击是巨大的。

目前还未发现有说自己是非公网环境下中招的，不过至少能确定昨天的疑问，就是 mitm 并不是正确的回应。

希望飞牛能尽快解决漏洞并给出官方的说明报告吧。

在脱敏的情况下可以透露出更多技术细节么，目前 OP 说明的一些东西感觉和 mitm 关系不是很大，特别是 OP 提到的“安全人员反馈我收到的就是疑似中间人攻击，问题源自于 5666 的明文 http 注入”，如果厂家的某个技术真这样说，那么至少这句话在我这是个减分项（不是针对打工人，而是针对企业，安全事件反馈用户的内容是应该经过内部讨论后的严谨说明）。当然也有可能 OP 描述的和技术细节有一些偏差。

OP 有提到也有其他使用 FNOS 出现类似的问题，那么建议 OP 和飞牛讨论后再考虑是否公布技术细节，如果这是一个在野的 0day ，那么公布细节会增加漏洞的传播，这种情况下我们只能希望飞牛团队能尽快修复这个洞并后续能说明漏洞细节。