Comet浏览器更新后无法访问局域网设备排查指南

问题现象：Comet更新后局域网服务突然失联

近期，Perplexity旗下的AI浏览器Comet在更新至版本 151.0.7922.47 后，部分用户在Reddit上反映了一个棘手的问题：浏览器无法再访问局域网（LAN）内的自托管服务和设备。

Comet是由AI搜索引擎公司Perplexity于2025年推出的AI原生浏览器，基于Chromium内核构建，深度集成了Perplexity的AI搜索和问答能力。它的目标是重新定义浏览体验，让用户在浏览网页的同时能够即时获得AI辅助的信息整理和回答。Chromium是Google主导开发的开源浏览器项目，几乎所有主流浏览器（除Firefox和Safari外）都基于它构建，包括Chrome、Edge、Brave、Opera、Vivaldi等。各浏览器厂商在Chromium基础上添加自己的功能和策略调整，形成差异化产品。这意味着当Chromium上游引入安全策略变更时，所有下游浏览器都会受到影响，但影响的时间点和程度取决于各厂商的合并策略和独立决策。作为一款新兴产品，Comet需要在快速迭代功能的同时跟进Chromium上游的安全更新，这种双重压力有时会导致某些使用场景下出现意料之外的兼容性问题。

据用户描述，在更新之前，他一直可以通过Comet正常连接到多个本地服务，包括：

• Plex 媒体服务器
• Proxmox 虚拟化管理平台
• 多个 自托管容器（self-hosted containers）

Plex是一款流行的个人媒体服务器软件，允许用户在家庭网络中搭建自己的流媒体平台来管理和播放电影、音乐等媒体文件。Proxmox VE（Virtual Environment）是一个开源的企业级虚拟化管理平台，基于KVM和LXC技术，广泛用于家庭实验室和中小企业的服务器虚拟化管理。自托管容器通常指通过Docker或Podman等容器化技术部署的各类服务，如密码管理器（Vaultwarden）、笔记应用（Outline）、智能家居控制台（Home Assistant）等。这些服务构成了技术爱好者的"数字主权"基础设施，使他们不依赖云服务商即可掌控自己的数据。自托管（self-hosting）运动近年来在技术社区蓬勃发展，其核心理念是用户应当拥有对自己数据和服务的完全控制权，而非将一切托付给大型云服务商。Reddit的r/selfhosted社区拥有超过50万订阅者，GitHub上awesome-selfhosted项目列出了数百个可自托管的开源替代方案。这一运动的兴起与隐私意识觉醒、云服务价格上涨、以及对平台锁定的担忧密切相关。

然而，安装更新后这些连接全部失效。说个细节，同一台设备上安装的Brave浏览器却完全正常，可以无障碍访问上述所有服务。这一对比清晰地表明，问题并非出在网络配置或服务端本身，而是Comet浏览器在此次更新中引入了某种变化。

用户已排查的方向

发帖用户是一位对自托管环境相当熟悉的技术玩家，他在寻求帮助前已经做过基础排查。他检查了macOS系统的隐私设置：

在 Privacy & Security > Local Network（隐私与安全性 > 本地网络） 中，Comet的全部8个实例都已设置为启用（enabled）。

从macOS Ventura（13.0）开始，Apple引入了更为精细的本地网络访问权限控制。当应用程序首次尝试发现或连接局域网内的其他设备时，系统会弹出授权提示。这一机制基于Apple的TCC（Transparency, Consent, and Control）框架实现，旨在防止恶意应用在用户不知情的情况下扫描或访问局域网资源。TCC框架是macOS安全架构的核心组成部分，它统一管理着应用对摄像头、麦克风、位置信息、通讯录、文件系统等敏感资源的访问权限，所有授权记录存储在受SIP（System Integrity Protection）保护的数据库中，即使是管理员也无法绕过。

用户提到的"8个实例"很可能是因为Comet的多进程架构——Chromium内核会为主进程、GPU进程、各个渲染进程、网络服务进程、存储进程等分别创建独立的网络访问请求，每个进程在macOS看来都是独立的网络访问主体，因此需要分别授权。这种多进程架构（Multi-process Architecture）是现代浏览器的标准设计，其初衷是实现进程隔离以提升安全性和稳定性——一个标签页的崩溃不会影响整个浏览器。值得深入理解的是，Chromium的多进程架构不仅仅影响稳定性，还深刻改变了与操作系统权限系统的交互方式。在macOS上，每个独立进程都被视为独立的网络访问主体，这是因为macOS的沙箱机制（App Sandbox）和网络扩展框架（Network Extension Framework）在进程级别进行权限判定。当浏览器的网络服务进程（Network Service Process）被独立出来后，实际的网络请求不再由主进程发起，而是通过IPC（进程间通信）委托给专门的网络进程处理。这意味着macOS的TCC数据库中需要为这个独立的网络进程单独记录授权状态，如果授权记录不完整或在更新过程中被重置，就可能出现权限看似已授予但实际未生效的情况。

换句话说，从操作系统的权限授予角度看，Comet理论上已经获得了访问本地网络的许可，但实际访问依然失败。这让问题更加扑朔迷离——权限没问题，同系统下的其他浏览器也没问题，唯独更新后的Comet无法工作。

深度分析：Chromium的本地网络访问新策略

作为一款基于Chromium内核构建的浏览器，Comet的这一异常很可能与Chromium近期推进的 本地网络访问（Local Network Access, LNA）安全机制 有关。

为什么会出现这种限制？

近年来，浏览器厂商越来越重视防范"DNS重绑定攻击"和"跨源本地网络请求"这类安全威胁。

DNS重绑定攻击（DNS Rebinding）是一种利用DNS解析机制绕过浏览器同源策略的攻击手法。攻击者控制一个恶意域名的DNS解析，先让该域名解析到攻击者的外部服务器IP，待浏览器完成初始页面加载后，再将同一域名的DNS记录切换为受害者局域网内的私有IP地址（如192.168.1.1）。由于浏览器认为请求仍然是发往"同一个域名"，同源策略不会拦截，攻击者的JavaScript代码便能自由访问受害者的路由器管理面板、NAS设备或其他内网服务，实施密码窃取、配置篡改甚至横向渗透。

这种攻击在智能家居设备日益普及的今天尤为危险。DNS重绑定攻击之所以引起浏览器厂商的高度重视，是因为物联网设备的爆发式增长极大地扩大了攻击面。据统计，平均每个家庭网络中连接了超过20个IoT设备，其中大量设备的Web管理界面缺乏认证机制或使用默认密码。2018年，研究人员演示了通过DNS重绑定在10秒内控制Google Home和Chromecast设备的攻击；2019年，类似技术被用于攻击Roku流媒体设备。攻击链通常是：受害者访问恶意网站→JavaScript代码等待DNS TTL过期→同域名解析切换到内网IP→发起API调用控制设备。传统的防御手段包括路由器DNS过滤（拒绝将外部域名解析为内部IP）、设备固件加入Host头验证等，但这些措施覆盖率极低，从浏览器层面实施PNA防护成为最有效的大规模解决方案。值得注意的是，传统防火墙对此类攻击几乎无能为力，因为攻击流量看起来完全是合法的HTTP请求，只是目标地址被"偷梁换柱"了。

恶意网页可能在用户不知情的情况下，利用浏览器向局域网内的路由器、NAS、管理面板发起请求，从而实施攻击。

Chromium社区为此推出了名为 Private Network Access（PNA，原名CORS-RFC1918）的安全规范，这是W3C正在推进的一项Web平台安全标准，由Google Chrome团队主导开发。该规范将网络地址空间划分为三个层级：公共网络（public）、私有网络（private，即RFC 1918定义的10.0.0.0/8、172.16.0.0/12、192.168.0.0/16等地址段）和本地主机（localhost/127.0.0.1）。RFC 1918是1996年发布的互联网标准文档，定义了三段保留给私有网络使用的IP地址范围——这些地址不会在公共互联网上路由，任何组织和个人都可以在自己的局域网中自由使用，无需向互联网号码分配机构申请。这一设计既缓解了IPv4地址枯竭问题（IPv4总共只有约43亿个地址），也天然形成了内外网的隔离边界。浏览器安全策略正是利用这一地址空间划分来识别和保护内网资源。

PNA规范要求：当一个来自较低安全层级的上下文（如公网页面）试图向较高安全层级的地址（如内网IP）发起请求时，浏览器必须先发送一个CORS预检请求（preflight），只有目标服务器明确返回允许的响应头（如Access-Control-Allow-Private-Network: true）后，实际请求才会被放行。CORS（Cross-Origin Resource Sharing，跨源资源共享）本身是Web安全的基石之一，它通过HTTP响应头来声明哪些跨域请求是被允许的。PNA本质上是对CORS机制的扩展——将"源"（origin）的概念从域名层面延伸到了网络地址空间层面。

PNA规范的发展历程充满了妥协和延期。最初在2020年以CORS-RFC1918的名义提出时，Chrome团队计划在Chrome 92中全面强制执行。然而由于大量企业内网应用、IoT设备管理面板、以及开发者本地调试环境依赖从公网上下文访问私有地址的能力，该计划被多次推迟。Chrome 94仅引入了开发者工具中的警告提示，Chrome 98开始在非安全上下文中阻止某些私有网络子资源请求，Chrome 104引入了预检请求但仅作为警告。到2024-2025年间，Chromium开始逐步将这些警告转化为硬性拦截，但具体的执行时间线因功能复杂度而不断调整。这种渐进式推进策略也解释了为什么不同时间点更新的不同浏览器会表现出不同的行为。

当一个页面试图访问比自身"更私密"的网络地址（例如从公网页面访问 192.168.x.x 或 10.x.x.x 的内网地址）时，浏览器会施加额外限制，甚至默认拦截。但需要注意一个微妙的区别：用户直接在地址栏输入内网IP访问服务（顶级导航）与网页中嵌入的脚本尝试访问内网资源（子资源请求），在PNA规范中的处理方式可能不同。前者通常不受限制，后者才是PNA主要针对的场景。如果Comet的问题连直接访问都受影响，则可能涉及更激进的实现策略或其他机制。

Comet在 151 版本中很可能同步或提前启用了这一策略，而Brave由于版本或策略配置不同，仍保持了旧的宽松行为。Brave浏览器虽然同样基于Chromium内核，但其开发团队在隐私和安全策略上有着自己独立的判断——对于那些可能影响用户正常使用体验的激进策略，Brave往往会推迟启用或提供更灵活的用户控制选项。Brave的开发理念更倾向于"用户至上"，他们甚至会主动移除某些Google在Chromium中加入的遥测和追踪代码。此外，Brave的版本更新节奏与Chrome并不完全同步，可能落后若干个版本，这意味着某些Chromium新引入的限制性策略在Brave中尚未生效。这种策略差异正是同为Chromium系浏览器却表现不同的根本原因。

macOS本地网络权限的双重门槛

需要特别指出的是，在macOS上访问局域网存在两道关卡：

1. 操作系统层面 —— 即用户已检查的 Privacy & Security 中的Local Network授权。这是Apple的TCC框架层面的权限控制，确保应用程序获得用户明确的知情同意。这一层面的控制粒度是"应用是否可以看到局域网上的其他设备"，类似于物理世界中"你是否被允许进入这栋大楼"。
2. 浏览器内部策略层面 —— Chromium自身的LNA/PNA拦截逻辑。这是浏览器引擎在Web标准层面实施的限制，即使操作系统已经放行，浏览器自身仍可能基于安全策略拒绝请求。这一层面更像是"即使你进入了大楼，保安仍然可以阻止你进入特定房间"。

这种分层安全模型（layered security）在现代操作系统中非常常见——每一层都独立做出安全决策，形成纵深防御（defense in depth）。用户仅解决了第一道关卡，第二道浏览器内部的策略拦截可能才是真正的元凶。

可行的解决方案

虽然这是一个较新的问题，但基于Chromium的行为特征，可以尝试以下几种排查和修复思路：

1. 检查实验性标志（flags）

在地址栏输入 chrome://flags（Comet中可能为对应的内部页面），搜索与 Local Network Access 或 Private Network Access 相关的实验性开关。

chrome://flags是Chromium内核浏览器提供的实验性功能管理页面，允许用户手动开启或关闭尚处于测试阶段的功能特性。这些"标志"（flags）本质上是功能开关（feature flags），是现代软件工程中渐进式发布（progressive rollout）策略的体现。开发团队可以将新功能隐藏在flags后面，先让一小部分用户测试，确认稳定后再默认启用。对于Private Network Access相关的标志，关键词通常包括"Block insecure private network requests"、"Private Network Access respect PreflightResults"、"Private Network Access preflight for navigations"等。需要注意的是，不同Chromium版本中这些标志的名称和数量可能有所变化，某些标志在正式启用后会从flags页面中移除。

如果发现相关标志被默认设为 Enabled，可尝试将其切换为 Disabled，然后重启浏览器。需要注意的是，修改flags可能带来安全风险，用户应在理解后果的前提下操作——禁用PNA相关保护意味着恶意网页可能利用你的浏览器作为跳板访问内网服务。

2. 使用HTTPS或配置本地域名

Chromium的本地网络限制对于安全上下文（HTTPS）通常更为宽松。这是因为PNA规范的一个核心原则是：来自安全上下文（Secure Context，即通过HTTPS加载的页面）的请求被认为更可信，因为HTTPS确保了页面的来源经过验证，不太可能是中间人攻击或DNS欺骗的结果。为自托管服务配置本地CA证书并启用HTTPS访问，或通过反向代理（如Nginx Proxy Manager、Traefik）分配本地域名，往往能规避纯IP+HTTP访问被拦截的问题。

为局域网服务配置HTTPS通常需要建立一套私有的证书颁发体系。常用方案包括：使用mkcert工具一键生成本地信任的开发证书（它会自动将根证书安装到系统信任存储中）；部署step-ca等轻量级私有CA服务器进行集中化证书管理（适合管理大量内网服务的场景）；或者利用Let's Encrypt配合DNS-01验证为内网域名签发公信证书（DNS-01验证不需要服务器可从公网访问，只需证明你对域名DNS记录的控制权）。反向代理方面，Nginx Proxy Manager提供了图形化界面简化配置，Traefik则以其自动服务发现和证书管理能力在Docker生态中广受欢迎，Caddy也因其自动HTTPS特性成为热门选择——Caddy默认为所有域名自动申请和续期证书，几乎实现了零配置HTTPS。配合Pi-hole或AdGuard Home等本地DNS服务器，可以将自定义域名（如plex.home.lan）解析到内网IP，实现既安全又便捷的访问体验。

3. 向Perplexity官方反馈

由于Comet是一款相对年轻的产品，此类因更新导致的功能回退（regression）很可能是官方尚未充分测试的场景。功能回退是软件开发中的常见问题，指新版本更新后原本正常工作的功能出现异常。对于浏览器这类复杂软件（Chrome的代码量超过3500万行），regression testing尤为重要——Chrome团队维护着数百万个自动化测试用例来捕获潜在的回退。但对于Comet这样资源有限的新兴浏览器团队，测试覆盖率可能尚未达到成熟产品的水平，尤其是在局域网访问这类边缘但对特定用户群体至关重要的场景上。建议受影响的用户通过官方渠道提交Bug报告，详细描述复现步骤和环境信息，等待后续版本修复。

4. 临时降级或使用备用浏览器

如果本地服务访问是刚需，在官方修复前，可暂时使用工作正常的Brave等浏览器访问自托管服务，等待Comet更新到修复版本后再切回。另一个选择是查看Comet是否提供版本降级机制或旧版本下载——但需要注意，使用旧版本浏览器可能暴露于已知安全漏洞之下，应权衡利弊。

对自托管用户的启示

这一事件对广大自托管（self-hosting）爱好者是一个重要提醒：浏览器的安全策略正变得越来越严格。随着LNA、私有网络访问限制等机制在各大浏览器中逐步落地，那些习惯于通过纯IP地址+HTTP直连内网服务的用户，未来可能会频繁遇到类似的访问障碍。

这一趋势并非孤例——浏览器近年来持续收紧安全策略的例子比比皆是：混合内容（Mixed Content）的逐步封杀、第三方Cookie的淘汰计划、FTP协议支持的移除、不安全端口的封锁等。每一次策略收紧都会让一部分依赖旧行为的用户措手不及。浏览器厂商的逻辑是"为99%的普通用户提供更安全的默认行为"，而1%的高级用户需要自行适应或寻找变通方案。

从长远看，为家庭实验室（homelab）中的服务配置规范的HTTPS证书和本地域名解析，不仅能提升安全性，也能更好地兼容未来浏览器的严格策略。将homelab服务访问方式现代化涉及一整套工具链的搭建。典型的现代化homelab网络架构包括：使用pfSense或OPNsense作为软件路由器/防火墙，部署VLAN隔离不同信任级别的设备（IoT设备、服务器、个人终端分属不同VLAN），运行CoreDNS或Unbound作为递归DNS解析器并集成本地区域配置，通过WireGuard或Tailscale实现安全的远程访问（Tailscale基于WireGuard协议并利用DERP中继服务器解决NAT穿透问题）。在证书管理方面，越来越多的用户采用ACME协议自动化证书生命周期管理——Traefik和Caddy都内置了ACME客户端，可以自动向Let's Encrypt或ZeroSSL申请证书。这种架构虽然前期投入较大，但一旦建立就能优雅地应对浏览器安全策略的持续收紧。

与其被动应对每次浏览器更新带来的"惊喜"，不如提前将本地服务的访问方式现代化。实际上，许多自托管社区的资深用户早已将"HTTPS everywhere + 本地DNS"作为homelab的最佳实践进行推广，这次事件只是再次证明了这一实践的前瞻性。

对于AI浏览器这类新兴产品而言，如何在拥抱Chromium安全升级的同时，兼顾技术用户的实际使用场景，也是产品团队需要认真权衡的问题。毕竟，自托管用户群体与AI浏览器的早期采用者群体高度重叠——这些技术爱好者既是最积极的尝鲜者，也是对网络自由度要求最高的用户。忽视他们的需求，可能意味着失去最有价值的一批种子用户。一个值得借鉴的做法是：在引入可能影响局域网访问的策略变更时，提供明确的用户提示和一键白名单机制，而非静默拦截让用户自行排查——这既尊重了安全原则，也体现了对用户体验的关怀。

核心要点

核心要点

核心要点