美国航空业在 2026 年 11 月 13 日经历了一次罕见的全国性航班停飞事件。 美国联邦航空管理局（FAA）因多个航路交通管制中心出现通信问题，发布全国范围的地面停飞令（Ground Stop），要求美国各地机场暂停航班起飞。   image1920×1041 484 KB   虽然停飞令随后解除，但航空运输系统并不能在禁令取消后立即恢复正常。大量航班延误、取消，飞机和机组人员也需要重新安排，整个航空网络的运行恢复需要一定时间。 美国全国航班停飞 这次事件发生后，美国多个机场的航班起飞受到影响。 需要注意的是，这次停飞并不是要求所有已经在空中的飞机立即降落，而是出于安全考虑，暂停或限制新的航班起飞。已经在空中的飞机则按照空管部门的安排继续运行。 即使 FAA 后续取消了地面停飞令，航空公司仍然需要处理大量积压航班、机组调度和飞机重新部署等问题。 因此，航班恢复正常往往比停飞本身需要更长时间。 老旧的空管通信网络再次成为焦点 从美国交通部和相关部门公布的信息来看，此次事件的直接原因是空中交通管制系统出现通信故障。 美国空中交通管制系统由多个区域性航路交通管制中心（Air Route Traffic Control Centers，ARTCC）组成，负责管理飞机在不同区域之间的飞行。 这些中心需要依赖通信网络、雷达、自动化设备和其他基础设施，确保飞机之间保持安全距离，并协调不同航班的飞行路线。 一旦关键通信链路出现问题，空管人员就可能无法正常获取或传递必要的信息。 在这种情况下，暂停航班起飞是保障航空安全的重要措施。 事实上，美国空管基础设施老化的问题已经存在多年。部分通信线路、无线电设备和自动化系统需要持续升级，才能满足现代航空运输日益增长的需求。 SMART 新一代空管系统也受到关注 此次事件还有一个值得关注的背景。 2026 年 11 月 10 日，FAA 宣布将 SMART（Strategic Management of Airspace, Routes and Trajectories，空域、航路与航迹战略管理）系统扩展至全美 22 个航路交通管制中心。 SMART 是一个基于云计算的空域管理系统，能够汇集天气、航班路径、空域流量以及空管人员配置等多种数据，为航空交通管理提供分析和调度建议。 根据 FAA 公布的信息，该系统整合了约 200 个数据来源，主要用于改善航班调度、减少延误和降低燃油消耗。 不过，SMART 并不是直接取代空管人员的自动驾驶系统。它负责分析数据并提供建议，最终仍由相关空管机构进行决策和执行。 SMART 上线与全国停飞是否存在联系？ SMART 系统刚刚完成全国范围的扩展部署，几天后美国便发生了大规模航班停飞事件。 两件事情在时间上高度接近，自然引起了媒体和公众的关注。 目前，FAA 和系统供应商均表示，此次事件源于通信网络故障，系统供应商也否认 SMART 是此次停飞的原因。 美国相关部门表示，将进一步调查通信故障的具体原因，以及是否存在其他潜在因素。 因此，目前还不能认定 SMART 系统与此次停飞存在直接因果关系。 不过，这次事件确实让人们重新关注一个重要问题：当一个国家的航空运输系统越来越依赖数字化和智能化技术时，底层通信基础设施是否足够可靠？ 美国航空运输系统是一个高度复杂的基础设施网络。 从机场塔台、区域空管中心，到全国性的通信网络和航班调度系统，每一个环节都需要保持稳定运行。 新一代智能化系统可以提高效率，但它们并不能完全解决底层基础设施老化的问题。 如果通信网络本身存在可靠性隐患，那么再先进的数据分析系统也无法完全弥补基础设施的不足。 这次全国性航班停飞事件，势必会让 FAA 的基础设施升级计划、系统采购、技术架构和项目管理再次受到公众审视。 技术升级不仅仅是部署新系统，更重要的是确保新旧系统能够可靠协同，并在发生故障时具备足够的冗余和恢复能力。 对于航空运输这样涉及公共安全的关键基础设施而言，稳定性和安全性始终应该优先于技术创新的速度。   https://www.isharkfly.com/t/smart/9525

这些年，大家不是忙着上云，就是忙着追 AI，好像不这样就跟不上时代潮流。 云计算和 AI 确实带来了很多便利，但技术潮流并不意味着所有业务都适合完全依赖云服务。尤其是在业务连续性和基础设施可靠性方面，上云并不等于万无一失。   Neon Cloud Outage Data Center1672×941 465 KB   2026 年 11 月 12 日，微软 Microsoft 365 发生全球性服务故障。此次事件主要影响 Exchange Online，导致部分用户无法正常访问 Outlook 邮箱，邮件投递也出现延迟。同时，一些依赖 Exchange Online 的 Microsoft 365 服务和功能，包括 Teams 日历、Copilot、Microsoft Graph 等，也受到不同程度的影响。 截至 11 月 13 日，微软仍在分阶段恢复受影响的基础设施。虽然服务可用性已经有所改善，但部分用户仍可能遇到间歇性访问问题和邮件延迟。 值得注意的是，微软尚未公布此次事故的最终根本原因，后续仍需等待官方事故报告。 健康检查也可能导致系统过载 在云计算和容器化系统中，健康检查（Health Check）是非常重要的机制。 举个例子，如果你在 AWS 上部署了 Docker 容器，并且更新了应用镜像，在采用滚动更新或蓝绿部署的情况下，通常可以在不中断服务的前提下完成版本升级。 一个典型的部署流程如下： 使用新的镜像创建容器实例。 等待容器启动，并进行健康检查（Health Check）。 健康检查通过后，将新实例加入负载均衡，并逐步切换流量。 确认新版本运行正常，完成流量切换。 将旧实例从负载均衡中移除，等待现有请求处理完成后再销毁。 如果没有负载均衡和多实例部署机制，直接重启单个容器或应用，通常就会造成短暂的服务中断。 对于个人博客和普通网站来说，几秒钟的中断可能问题不大，但对于支付系统、交易系统和企业办公平台来说，这种中断可能造成实际业务损失。 问题往往出现在第二步：健康检查。 如果应用启动时间较长，而健康检查的超时时间、重试次数或启动宽限期设置得不合理，系统就可能过早地将尚未完成启动的实例判定为不可用。 接下来可能出现这样的情况： 新实例因为健康检查失败而无法接收流量。 负载均衡器将流量集中分配给其他正常实例。 剩余实例承受更大的请求压力。 部分实例因资源不足而变得不可用。 更多实例被移出服务集群。 最终，一个局部故障就可能演变成整个系统的连锁故障（Cascading Failure）。 AWS ECS 等平台提供了健康检查宽限期、部署失败检测和自动回滚等机制，但具体行为取决于部署策略和参数配置，并不存在统一的固定故障等待时间。 基础设施冗余度是否足够 从此次 Microsoft 365 故障可以再次看到，云服务的可靠性不仅取决于服务器数量，还取决于整个基础设施的冗余设计和故障隔离能力。 一个真正可靠的云平台，至少需要考虑： 计算资源冗余： 单个服务器或实例出现故障时，其他实例能够接管业务。 网络冗余： 避免单一网络路径或网络设备成为故障点。 跨区域容灾： 单个数据中心或区域出现故障时，其他区域能够提供必要的服务。 容量冗余： 即使部分服务器下线，剩余服务器也有足够的处理能力。 故障隔离： 一个服务出现问题时，不应该无限制地影响其他服务。 如果一个系统在没有足够冗余容量的情况下运行，那么即使只是部分服务器出现故障，也可能导致剩余基础设施承受过高负载，最终形成连锁反应。 当然，不能仅凭这次事故就认定微软的最终问题一定是冗余不足，具体原因仍需要等待官方事故报告。 云服务并不意味着绝对可靠 微软以及其他大型云服务商经常强调自己的高可用性、容灾能力和服务等级协议（SLA）。 但是，SLA 并不等于服务永远不会中断。 对于企业而言，真正需要考虑的是：如果云服务商发生大规模故障，自己的业务是否还有其他运行方式？ 例如： 企业内部是否保留必要的数据备份？ 是否有独立于云邮箱的紧急通信方式？ 关键业务是否存在备用处理流程？ 是否能够在云服务恢复之前维持最基本的业务运转？ 这些问题比单纯关注云服务商承诺的可用性百分比更加实际。 上云之前，应该考虑什么 云计算有自己的优势，但并不是所有基础设施都应该无条件地迁移到云端。 对于企业来说，合理的架构应该根据业务重要性、成本和可靠性要求进行选择。 有些业务适合完全使用 SaaS 服务，有些业务则需要保留本地基础设施，还有一些关键业务可能需要采用混合云或多区域部署。 真正重要的不是是否使用云，而是当云服务出现问题时，业务是否还有继续运行的能力。 很多基础设施上云，并没有宣传中那么美好。   https://www.isharkfly.com/t/o365/3713

这又是那个不长眼的把系统更新坏了？     本以为是一个安静祥和的一天，中饭后就一致报系统故障。 Team 里面的消息都快爆炸了，直接先退一下，太吵了。     outlook 是这样的，基本上可以先放羊。 https://www.isharkfly.com/t/office-365/12099

都说资本是无情的，在对自己人手上也展现出无情的一幕。 英伟达迅速换掉 CEO，完成与负面消息的切割。     都说黄仁勋几天前还出现在英伟达的总部和董事会，感觉是不是在和董事会商谈“离职补偿”。 这几天，英伟达的消息确实不太好看，其中可能还涉及到很多东西外界都不知道。 但不久，黄仁勋需要到国会去接受质询，这个时候他还是以 英伟达 CEO 的身份去接受质询的话，显然对英伟达不好看。 光速换掉 CEO，能够迅速和负面消息进行切割，也能顺便安抚下华尔街。 至于老黄的下一步，估计也就是赔偿的赔偿，离婚的离婚，不过他也不用担心养老，早已足够，但在芯片领域的话语权将会极大的削弱和边缘化。   https://www.isharkfly.com/t/topic/12098

自从被盯上，百度发了侵权通知后被认定为侵权，就知道早晚会轮到腾讯上面的几篇有那么一点点关联的内容。 以前看到一些公司对事故的处理上让人莫名其妙，这何尝不是整个基因使然，从现实环境到虚拟环境都没放过。 果不其然，早在一周前就已经有投诉发给腾讯，只是一直没有来得及查看罢了。 早上突然拿到一个通知说投诉不通过，用人话来说就是投诉内如不符合法定处理条件，对我们来说简单点的就是文章内容不涉及侵权。 一些公司极度喜欢在各个平台上投诉，这次也算踢到了铁板，不过他们是不会长记性的。 新一代的互联网用户，早就没有早期拨号上网用户对获取的信息和言论上面的责任感，为了流量很多超越底线的事情都可以做。 同时，也很擅长使用手段对付一些自己不想让人看到的信息，不少平台为了避免后续的麻烦，基本上对投诉就是默认成立，反正多一个一个不多，少你一个不少。 腾讯的这次做法让我感觉有了不少的好感，至少对于文章的内容，他们是看过的，不是无脑同意。 老一代的互联网人再过几十年就可以收队了，互联网对这我们这一代人的记忆远远超过了小视频的影响，从论坛和博客开始，虽然早期的网络上也有各种骂架，但自始至终还保留了一些最基本的体面。   https://www.isharkfly.com/t/topic/3711

英伟达（NVIDIA）创始人兼CEO黄仁勋于2026年11月8日向全体员工发送内部信，公开承认自己存在婚外情并对妻子不忠。 11月8日还正好是个周末。 这封内部信已由英伟达官方公开发布。   信件内容比较短，不复杂，其中提到了涉及到的安全问题，具体内容是什么，《纽约时报》上也有了详细的时间线和背景介绍。 吃瓜的自己去找找，很容易就能获取。 在国家利益面前，再强大的企业也扛不住。 N 年前有个相声的段子是这样说的：再大的大款也大不过公款。 影响 这件事情本身的影响不会简简单单的局限于英伟达的内部。 情报系统的调查一直在跟进，现在应该就是到底知道了多少，还有多少不知道的。 为什么共和党自己在输掉中期选举后选择公开，这个消息早就不是新闻了。 对 AI 算力，泡沫，格局的影响怎么样？ 资本市场对 AI 从基础架构到应用会不会进行新一轮的评估。 这些问题在随后的几个月慢慢的应该会出现，让我们坐好扶稳。   https://www.isharkfly.com/t/nvidia/10083

开启 Early Bird 功能即可。 在使用 Opera 浏览器的过程中，如果希望通过 Browser Connector 将浏览器连接到 ChatGPT、Claude 等外部 AI 服务，并通过 MCP（Model Context Protocol）实现网页内容读取、页面交互等功能，可能会遇到一个问题： 在 Opera 设置中找不到 Browser Connector，或者虽然看到了相关选项，却无法点击 Install 按钮。 这通常与 Opera 的实验性功能设置有关。 问题现象 在 Opera 的设置页面中，进入 AI Services，可以看到 Browser Connector 相关配置。     Browser Connector 的主要功能包括： 将浏览器连接到外部 AI 服务，例如 ChatGPT 和 Claude。 允许 AI 服务获取网页内容。 支持通过 MCP 与浏览器进行交互。 根据授权情况，支持访问网页内容和执行相关浏览器操作。 但是，在某些版本或配置下，Browser Connector 的安装按钮可能处于不可用状态，或者相关功能根本没有显示。 解决方法：开启 Early Bird Opera 的部分实验性功能需要通过 Early Bird 设置启用。     具体操作如下： 第一步：打开 Opera 设置 在地址栏输入： opera://settings 进入浏览器设置页面。 第二步：进入 Early Bird 在左侧设置菜单中找到 Early Bird。 Early Bird 是 Opera 用于体验和测试实验性功能的入口。 如果 Early Bird 当前处于关闭状态，先将其开启。 第三步：启用 Browser Connector 开启 Early Bird 后，重新查看 Early Bird 设置页面。 此时应该可以看到 Browser Connector 选项。 将 Browser Connector 开关打开。 注意：部分设置可能需要点击 Reload 或重新启动浏览器才能生效。 第四步：安装 Browser Connector 完成上述操作后，进入： opera://settings → AI Services 找到 Browser Connector，点击 Install。 安装成功后，Browser Connector 会出现在浏览器工具栏中，可以进一步管理连接和相关权限。 如何验证是否启用成功？ 可以通过以下几个方面检查： Early Bird 中的 Browser Connector 开关已经开启。 AI Services 中的 Browser Connector 已经完成安装。 浏览器工具栏中出现 Browser Connector 入口。 可以根据需要配置外部 AI 服务及其连接权限。 Early Bird 属于实验性功能，启用后可能出现不稳定情况。     如果开启 Early Bird 后仍然找不到 Browser Connector，建议检查 Opera 版本，并确认当前版本是否提供该功能。 如果在 Opera 中找不到 Browser Connector，或者安装按钮不可用，可以先检查 Early Bird 是否已经开启。 这样就可以进一步探索 Opera 浏览器与 ChatGPT、Claude 等 AI 服务通过 MCP 实现集成的能力。   https://www.isharkfly.com/t/opera-browser-connector/10081

在湖南永州，潇水与湘江交汇之处，有一座沉淀着千年历史的古村落——老埠头。 这里曾是潇湘水路上的重要渡口，也是湘桂交通要道上的商贸重镇。千百年来，江河在此交汇，商船在此停泊，南来北往的商旅在这里留下足迹。如今，昔日繁华的水陆码头虽然渐渐归于平静，但青石板古街、古码头、老商铺和斑驳的石碑，依然默默诉说着这座古镇的历史。 潇湘交汇处的古老村落 老埠头村位于湖南省永州市冷水滩区蔡市镇南部，地处潇水与湘江交汇区域，依江而建，因水而兴。 这里东临湘江，南接沙坪里村，西邻大园山村，北靠九牛岭村。独特的地理位置，使老埠头自古便成为连接湘江、潇水两大水系的重要交通节点。 潇水发源于九嶷山，蜿蜒北上，在永州与湘江汇合。两江交汇，不仅形成了独特的自然景观，也为当地航运和商贸发展提供了得天独厚的条件。 据《老埠头新加义舟记》记载： 潇水自九疑百折而入于永州北十里之老埠头，与湘水会合，为最古之名区。老埠头于唐代兴起，五代时设有镇，曰潇湘镇，明时改设驿丞曰湘口驿。驿前二水横亘，深阔若无限然，为吾乡所必经之要渡…… 这段碑文记录了老埠头的历史沿革，也揭示了它在潇湘水路交通体系中的重要地位。 从潇湘镇到湘口驿 老埠头的历史可以追溯到唐代，历经五代、宋、元、明、清多个朝代，逐渐发展成为湘江流域的重要渡口和商贸集镇。 五代时期，这里设立潇湘镇，承担着地方管理和交通防守等职能。到了明代，随着水路交通的发展，老埠头又设立湘口驿，成为官方驿传和民间往来的重要节点。 湘口驿前，潇水与湘江交汇，两江水面开阔，渡口成为两岸居民和往来商旅必经之地。 当时，依托两江航运，老埠头形成了四通八达的水路交通网络：沿潇水而上，可以通往零陵、道州；沿湘江而上，可以连接全州等地；顺湘江而下，则可通往衡州、潭州等地。 凭借优越的水运条件，老埠头逐渐成为湘桂之间的重要交通节点，也是永州与宝庆之间的重要通道和物资集散地。     从唐代的渡口，到五代的潇湘镇，再到明代的湘口驿，老埠头的历史变迁，实际上也是潇湘地区水路交通和商贸发展的一个缩影。 繁华商埠留下的历史印记 老埠头最具特色的历史遗存，是至今仍然保留的古街、古商铺、古码头和古碑刻。 古街依山傍水，青石板与河卵石铺就的街道蜿蜒延伸。昔日，这里商铺林立，客栈云集，往来的商人、船工和旅客汇聚于此，形成了热闹的商业街区。 街道两旁曾有不少传统商贸建筑，采用下店上住、前店后院等布局形式。青砖青瓦、木质门窗、传统柜台以及具有地方特色的建筑装饰，展现了明清以来湘南地区传统商业建筑的风貌。     古码头则是老埠头昔日繁荣的另一处见证。码头沿江而建，石阶层层向下延伸，方便船只停靠，也方便货物装卸。商船往来、货物集散，构成了当年老埠头最鲜活的生活图景。 除了古街和古码头，村中还保存着多块具有历史价值的石碑。其中，《老埠头义渡始末记》和《老埠头新加义舟记》等碑刻，记录了当地渡口的修建、维护以及义渡运营等历史情况。 这些碑刻不仅是研究老埠头历史的重要实物资料，也是了解当地交通、商贸和民间社会生活的珍贵依据。 据 2023 年的专家勘察资料显示，老埠头部分古建筑已经严重残损。 一座古镇的文化价值 老埠头不仅是一处古老的水运码头，也是一座承载着丰富地方文化记忆的历史古镇。 2011年，老埠头古建筑群被公布为湖南省文物保护单位。其古街、古商铺、古码头、古驿道和碑刻等历史遗存，共同构成了潇湘古镇独特的文化景观。 这些建筑和遗迹记录着当地曾经的商业繁荣，也见证了潇水与湘江沿岸居民的生活方式和社会变迁。 对于研究永州地区的历史交通、古代商贸和地方社会文化而言，老埠头具有重要的历史价值。 流淌在潇湘之间的乡愁 如今，随着现代交通方式的发展，昔日繁忙的水路运输逐渐退出历史舞台，老埠头也从曾经的商贸重镇回归宁静。 然而，古镇的历史并没有因此消失。 江水依旧流淌，青石板依然铺展在古街之上，古老的码头和斑驳的石碑仍然记录着岁月的痕迹。那些曾经穿梭于潇水和湘江之间的商船，那些在古街上经营生意的商贩，以及往来于渡口两岸的普通百姓，都已经成为历史的一部分。     老埠头的价值，不仅在于它曾经有过怎样的繁华，更在于它为今天的人们留下了一段可以触摸、可以阅读的地方历史。 一座古镇，因水而兴，因商而盛，也因历史遗存而得以延续。 永州老埠头，这座潇湘交汇处的千年古镇，依然静静地守望着两江流水，诉说着属于潇湘大地的历史与乡愁。   https://www.isharkfly.com/t/topic/10077

2026年11月1日中午12时50分左右，一架注册号为 N722BD 的庞巴迪里尔60（Bombardier Learjet 60）双发公务机在佛罗里达州棕榈滩县格林埃克斯（Greenacres）附近坠毁，机上9人全部遇难。 据NTSB委员汤姆·查普曼（Tom Chapman）在11月2日的发布会上介绍，该机由 Aurora Aviation（以 Upper Jets 名义运营）执飞，当天上午约10时37分从奥斯汀-伯格斯特罗姆国际机场起飞，目的地是巴哈马的北伊柳塞拉岛。 飞机坠落在主干道上。坠机在路面砸出一个弹坑，碎片散落四周，所幸地面无人员伤亡报告；附近一处移动房屋社区约600名居民被迫疏散。 据报道，这是有记录以来里尔60机型最致命的一次事故，也是今年美国第二严重的航空事故，仅次于6月密苏里州巴特勒一架跳伞飞机造成12人死亡的事故。 超高下降率 从航迹数据和陆空通话来看，这架飞机在一分钟左右的时间里从巡航高度直接坠地。 ADS-B 数据显示，飞机曾爬升至41,000英尺，之后在那不勒斯附近下降到约35,000英尺。事故发生前，飞机曾短暂爬升，随后进入一个陡峭的右转下降，在航迹信号消失前记录到的最大下降率超过每分钟32,000英尺。 机组的无线电通话记录了失控的全过程。飞行员先报告"Mayday"，称正以每分钟10,000英尺下降；下一次通话则称飞机处于超速状态，下降率达每分钟20,000英尺。约35秒后通话中断，最后一句话是"我们没时间了"。   查普曼在发布会上确认了这一时间点：大约12时48分，飞机发出了"处于超速状态、正在下降"的通话。 更值得关注的是，他透露已有部分证据显示飞机在撞地前发生了解体，调查人员可能会在距坠机点一定距离的地方找到飞机部件。 作为参照：正常航班下降率通常在每分钟1,500至3,000英尺左右，每分钟30,000英尺以上意味着飞机已接近垂直俯冲，远超其设计包线。 一旦进入这种状态，结构载荷和空速都已不在机组可控的范围内，这正是"无力回天"的原因。 气象原因 天气是本次调查的重点方向。NTSB表示，机组在飞机进入超速和急速下降前不久，曾报告遭遇轻度明冰和中度颠簸。飞行员当时还向迈阿密航路管制中心报告外界气温为零下47摄氏度。 据通话录音，飞行员还提到飞机上下颠簸幅度高达700英尺，随后才宣布紧急状态。当时该区域有分散雷暴，飞机在开始下降前几分钟曾穿过一个较强的雷暴单体。 机组最初请求爬升至37,000英尺以避开中度颠簸，管制员批准了这一请求。 不过查普曼在发布会上明确保持了谨慎：他表示天气条件是调查的主要关注点，需要确定的是约35,000英尺高度上的实际天气状况。他强调调查尚处于早期阶段，不会对事故原因作任何推测。NTSB也指出，结冰会让飞机的航迹和空速更难控制，甚至可能导致飞机无法维持平飞。 飞行员过度年轻化 事故发生后，副驾驶的年龄引起了广泛关注。遇难副驾驶是一名20岁的女性，名叫 Nathalia Filgueiras，毕业于西博卡拉顿高中，她拿到飞行执照的时间甚至早于驾照。 在公务机和包机运营中，年轻、飞行小时数较少的副驾驶并不罕见，这也是行业内长期讨论的话题：遭遇雷暴、结冰和高空颠簸叠加的复杂局面时，机组整体经验是否足以应对？ 但需要强调的是，截至目前NTSB尚未公布机长和副驾驶的飞行经历，也没有将机组经验列为事故原因。 查普曼只表示，调查将审视机组和管制员在什么时间掌握了哪些信息，以及各自采取了什么行动。 机组资质是否构成因素，需要等待正式调查结论。   https://www.isharkfly.com/t/n722bd/11024

群晖勒索事件，虽然我们没有中招，但 NAS 是开放公网访问，先改了吧。 勒索 大量群晖（Synology）NAS设备近日遭到名为 C3RB3R（Cerber变种） 的大规模勒索病毒攻击，文件被加密为 .LOCK3D 或 .L0CK3D 后缀，并在目录中留下 read-me3.txt 勒索信。 群晖官方紧急发布公告，确认有NAS用户遭加密数据并勒索赎金，官方初步排查认为攻击者利用了2024年12月已修补的CVE-2024-10441漏洞（CVSS 9.8分），并列出各分支的最低安全版本。 DSM 6.2：升级至6.2.4-25556-8或更高版本 DSM 7.1：升级至7.1.1-42962-7或更高版本 DSM 7.2：升级至7.2-64570-4或更高版本 DSM 7.2.1：升级至7.2.1-69057-6或更高版本 DSM 7.2.2：升级至7.2.2-72806-1或更高版本 不管怎么样，先更新版本。     检查了，我们后端的版本是最新的，因为我们一直保持自动更新。 禁止外网访问 有不少的地方要配置。 关闭 QuickConnect QuickConnect 不需要端口转发就能从外网访问，最容易被忽略。 控制面板 → 外部访问 → QuickConnect，取消勾选"启用 QuickConnect"，然后点应用。     删除 DDNS 控制面板 → 外部访问 → DDNS，把已添加的 DDNS 条目删掉（例如 xxx.synology.me）。 还好，我们没有 DDNS 条目。     清除端口转发 / UPnP 群晖端：控制面板 → 外部访问 → 路由器配置，删除所有已创建的转发规则。 路由器端：登录路由器后台，删除指向 NAS 的端口转发（常见的是 5000/5001、6690、443、80 等），检查 NAS 有没有被设为 DMZ 主机。最好同时关闭路由器的 UPnP，防止 NAS 或其他套件自动开端口。     用防火墙兜底 控制面板 → 安全性 → 防火墙，勾选"启用防火墙"，编辑规则： 先添加允许规则：端口选"全部"，来源 IP 选"子网"，分别添加你的内网网段，例如 192.168.0.0/255.255.0.0、10.0.0.0/255.0.0.0、172.16.0.0/255.240.0.0。 在下方"如果没有符合的规则"选择拒绝访问。 注意一定要先加允许内网的规则，再设拒绝，否则会把自己锁在外面。如果开了 IPv6，也要考虑加上 fe80::/10 等 IPv6 内网规则或直接关闭 IPv6。     这里的配置要小心点，首先防火墙要开启自动可以访问的配置。 类似一个服务器，如果你开防火墙之前，不开 22 端口，结果你自己也没有办法 SSH 到服务器上了，整个服务器要重装。 对于没有怎么玩过的，或者机器上面有重资产的一定要小心。 如果公司或者家庭中部署了 NAS ，现在的 NAS 基本上 7X24 运行的机器，等于就是一台服务器，上面可能会保留有公司的重要文档和资产，及时做好冷备份，更新软件才能避免不必要的麻烦。   https://www.isharkfly.com/t/nas/10076