# MatrixFlow 浏览器知识库：完整资料 > 用可检查的例子解释浏览器指纹、Cookie、本地存储、代理、WebRTC 与会话隔离，帮助多账号业务理解技术边界，并链接原始技术资料。 更新日期：2026-10-18 ## 浏览器指纹和 Cookie 有什么区别？ URL: https://learn.matrixflow.cn/guides/fingerprint-vs-cookies/ 摘要：Cookie 是网站让浏览器保存并在符合条件的请求里带回的数据；浏览器指纹是对环境特征的组合观察。清除 Cookie、调整浏览器环境和改变网络出口处理的是不同层面，任何单一操作都不等于账号获得平台许可。 ### 核心结论 - Cookie 是网站保存的数据；浏览器指纹是网站对环境的观察，两者不是一回事。 - 清 Cookie、改环境、换网络分别处理不同层面，任何一项都不等于平台许可。 - 判断问题先看页面提示、账号状态和权限，不要把所有异常都归因于指纹。 ### 一个是保存的数据，一个是观察到的特征 依据 MDN，Cookie 常用于维持会话；指纹则可能组合浏览器版本、语言、时区、字体和屏幕等特征。网站既可以读取符合条件的已有状态，也可以观察浏览器提供的信息，两条路径并不互相替代。这里解释的是通用机制，不代表某个平台公开了其全部识别逻辑。 对业务使用者而言，可以把它们分别记为“网站保存了什么”和“访问环境表现出什么”。账号身份、网站权限与后台记录还在第三个层面。把这三个层面分清，排查登录异常时就不会一上来清空所有数据或随意改设置。 ### 用三个问题定位实际问题 以上是 MatrixFlow 团队的排查建议。每次只改一个变量并保存前后结果，使用获授权的测试账号。真实业务中需要保留的草稿、购物车或本地偏好，清理前应先确认归属和备份方式。 - 页面要求重新登录：先确认账号状态、是否退出过、会话是否失效，不先断言是指纹问题。 - 页面语言或排版不符合预期：检查网站语言选项与环境设置，记录实际变化，不凭感受判断。 - 某个操作被限制：读取平台提示并核对权限、业务规则与数据条件，环境管理不能代替权限申请。 ### 购买和验收时应问什么 不要只问“能不能防关联”。可以要求演示：两个测试环境登录不同账号后是否保持各自状态；关闭重开以后能否回到正确账号；代理配置是否对目标环境生效；任务是否能明确指出自己操作了哪个账号。每项都要有实际页面或文件作为证据。 检测页显示的某个分数只描述该检测方法的结果，不能直接推导出业务平台会如何处理账号。更有价值的记录是具体版本、测试条件、观察结果和仍未验证的范围。选择工具时看自己需要管理哪些资料、允许什么操作、能否定位错误，以及维护成本是否可以承担。 指纹浏览器适合讨论环境组织与业务隔离需求。它不能替账号提供真实经营资料，也不能保证免验证或免处罚。把技术配置与平台规则分别处理，有助于形成长期可维护的工作方式。 ### 用三种现象判断问题在哪一层 现象一：关闭浏览器后仍保持登录，通常与网站保存的 Cookie 或其他存储、服务器会话有关；现象二：换了网络出口但网站仍识别到同一登录账号，说明账号会话与网络路径是两回事；现象三：清理站点数据后要求重新登录，是会话数据被移除的可能表现。它们都不能单独证明网站使用了哪种识别策略。 浏览器指纹指网站从浏览器或设备可观察特征推测环境相似性的过程。可观察字段可能包括语言、时区、屏幕和图形能力等，但不同网站采用的信号与方法不同。不要把“指纹”理解成一个固定、可直接读取的唯一编号，也不要把单一字段变化当成匿名或合规保证。 - 登录持续：检查 Cookie、站点存储和服务端会话。 - 网络访问异常：检查代理与连接路径。 - 平台安全提示：遵循平台验证流程，不以更换环境规避。 ### 选工具前先写出要解决的问题 先说明业务目标，例如团队需要把不同店铺的登录资料分开管理，还是需要记录每个账号由谁负责。再比较数据隔离、权限管理、代理兼容性、备份恢复、团队审计和成本。用明确的验收任务确认厂商承诺是否真实可用，不能只看“防关联”这类结果性宣传。 最小验收例子：在测试账号中分别登录两个环境，检查打开后的身份、Cookie 状态、标签复用、退出后的持久化行为；测试前先确认平台规则允许该账号使用方式。验收记录写实际观察，不写“100%安全”或“不会关联”。 - 要求供应商说明环境数据保存在哪里、如何导出和删除。 - 先用非生产测试账号检验，再迁移真实业务。 ### 常见问题 **清 Cookie 能解决登录异常吗？** 有时能触发重新登录，但不能保证解决；先看平台提示和账号状态，清理前确认未提交草稿等数据。 **指纹检测分数越高越安全吗？** 不能这样判断。分数只反映该检测方法在当次环境下的结果，平台如何处理账号是另一套规则。 ### 参考资料 - MDN：Fingerprinting 术语说明: https://developer.mozilla.org/en-US/docs/Glossary/Fingerprinting - MDN：HTTP Cookie: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies - MDN：HTTP Cookie: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Guides/Cookies --- ## 多开标签页为什么不等于隔离账号？ URL: https://learn.matrixflow.cn/guides/storage-session-isolation/ 摘要：标签页是页面的容器，账号会话还取决于网站使用的存储与服务器状态。仅把同一网站放到两个标签页里，不足以证明两个账号的数据已经隔离；应在实际环境中检查登录身份和数据是否互相影响。 ### 核心结论 - 标签页是页面容器，不等于独立账号环境；同上下文通常共享 Cookie 和本地存储。 - 隔离要用独立环境或独立上下文，并用两个测试账号实际验证。 - 清理站点数据前先确认草稿、购物车和本地偏好的归属。 ### 先分清标签、来源和环境 MDN 说明，localStorage 按来源区分；sessionStorage 还与标签页会话有关。Cookie 的发送范围则受域名、路径等条件约束。网站可以同时使用多种存储方式，因此“新建了一个标签”不是完整的会话隔离描述。来源通常由协议、主机和端口共同决定，也不能只看页面标题是否不同。 自动化工具的上下文也有自己的设计。例如 Playwright 用浏览器上下文组织隔离的测试状态；这是该工具的机制说明，并不证明其他软件中的任意窗口已经有同等边界。产品验收应检查实际行为，而不是只比较界面上的窗口数量。 ### 设计一个最小、无破坏性的隔离检查 以下为 MatrixFlow 团队建议的测试方法：准备自己拥有权限的两个测试账号，分别放入两个明确命名的环境。先登录账号A并记录页面身份，再登录账号B；回到A刷新页面，检查身份是否仍是A。随后分别关闭重开，观察是否回到各自预期状态。测试只读页面，不涉及真实订单更改或对外发布。 如需进一步检查，可在自有测试网站里给两个环境设置不同的无敏感标记，再读取标记是否串到另一边。一个测试站的结果只说明该项条件下的表现，不能扩展成所有平台、所有存储机制都已经验证。重启后登录失效也可能源于服务端策略，需要结合错误提示继续分析。 ### 维护隔离时容易忽略的细节 对团队交接，记录“哪个环境对应哪个业务账号”比记录“开了几个窗口”更实用。账号停用以后应同步清理人员访问权限与业务清单，而不是认为删除本地窗口就撤销了网站权限。环境隔离只是工作管理的一部分，权限和数据生命周期需要另外管理。 - 切换账号前看页面显示的业务身份，避免只认环境编号。 - 导入、复制或恢复环境资料时，检查是否带入了原账号的会话数据。 - 同一环境里不要同时安排相互冲突的写入任务，避免编辑状态被覆盖。 - 清理站点数据前检查未提交草稿；清理后按正常登录流程恢复。 ### 来源、存储和浏览器上下文的区别 网页的同源通常由协议、主机名和端口共同决定；Cookie 则可设置作用域，Web Storage 还按来源和存储类型工作。因此，同一站点的两个标签页往往共享相应浏览器上下文中的会话数据。仅仅打开两个标签，不等于创建两套独立账号环境。 不同浏览器上下文可形成不同的页面与存储边界，但实际产品如何保存、恢复和隔离资料，要以该产品的实现与版本为准。服务器也可能根据登录账号、授权令牌、设备和风险信号维护会话。对隔离性的结论应限定为你亲自测试过的范围。 - 记录当前浏览器上下文、来源与账号别名。 - 检查 Cookie、localStorage 和 sessionStorage 时不要导出真实令牌。 - 退出测试后确认另一个测试环境身份没有变化。 ### 设计不会误删数据的最小检查 使用两个专用测试账号和不含真实客户资料的测试站。分别在环境 A、B 登录后，从页面读取明显不同的测试标记；关闭并重开目标环境，再检查账号身份和标记是否保持；在 A 退出时再次读取 B。测试前导出或备份测试数据，避免用清除全部站点数据来验证单一行为。 如果两个环境显示同一账号、退出一个环境影响另一个，记录发生步骤、网站来源和产品版本。不要把原因直接归结为指纹：可能是同一浏览器上下文、共享凭据、站点 SSO 或测试账号本身复用。 - 预期：A、B 始终显示各自测试账号标识。 - 不符合预期：停止生产操作，保留复现步骤和时间。 ### 常见问题 **无痕窗口能隔离账号吗？** 无痕窗口会限制部分本地保存，但不等同于完整的多账号环境管理；仍需实际检查登录与存储是否互不影响。 **关闭重开还会保持登录吗？** 取决于网站会话策略和 Cookie 有效期，不能仅凭是否保存了 Cookie 判断。 ### 参考资料 - MDN：Web Storage API: https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API - MDN：Cookie 作用范围: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies - Playwright：浏览器上下文隔离: https://playwright.dev/docs/browser-contexts - MDN：Web Storage API: https://developer.mozilla.org/zh-CN/docs/Web/API/Web_Storage_API --- ## 代理能改变什么，不能改变什么？ URL: https://learn.matrixflow.cn/guides/proxy-network-boundaries/ 摘要：代理处理的是请求经过怎样的网络路径；它不自动处理浏览器里保存的登录状态，也不授予网站操作权限。选择代理时应分别检查协议适配、认证、目标站连通性和业务需要，不能只看一个出口地址或测速数字。 ### 核心结论 - 代理改变请求路径，不处理 Cookie、本地存储和账号权限。 - 代理采购要分别测试协议、认证、目标站连通性和业务任务。 - 故障按网络层、页面层、会话层、业务层逐层定位。 ### 把网络、会话、权限分开看 MDN 介绍的代理是客户端与服务器之间的中间节点，代理请求还可能包含转发信息。因此经过代理不等于所有信息都被隐藏。Cookie 和站点存储负责另一类状态，网站账号的权限又由网站管理；网络能通、已经登录、有权执行某项操作，是三个不同结论。 举例说，某个店铺后台能够打开，但是没有发货按钮，可能是岗位权限或订单状态问题。换一个网络出口不能代替给员工分配权限。同样，看到登录页面时，先正常登录并检查账号，不应自动认为代理失效。 ### 采购前写清自己的测试条件 下面是 MatrixFlow 团队的选型方法：列出目标网站、使用时间段、预计任务类型和允许的区域，向服务商确认协议、认证方式、流量计费与支持范围。先取小范围测试配置，用同一台电脑和同一个只读页面复测，记录首次打开、刷新和持续访问的情况。避免一次购买大量线路后才发现协议不适配。 延迟低不代表业务任务一定快。页面还可能受到文件大小、目标网站响应、账号权限与本机资源影响。测试结果应包含发生时间、页面地址和具体错误，而不是只写“很卡”。涉及上传下载时另外测文件传输，读取页面的结果不能替代素材上传表现。 ### 怎样判断故障在哪一层 只修改当前层面的一个条件，成功后再继续下一层。遇到证书警告、网站验证或权限不足，应停止相关操作并正常处理，不把跳过安全检查当作连通性修复。凭据与认证地址属于敏感资料，分享排障记录时先隐藏。 最后用实际业务成功标准收尾：例如正确账号下读到了指定订单，或确认草稿已经出现在列表。代理连通性报告应与业务结果分别记录，这样后续维护人员能知道已验证的范围，也不会把网络故障误认为内容或订单没有提交。 - 代理连接层：服务地址、端口、协议和认证是否正确，服务是否过期。 - 页面访问层：普通页与目标页是否都能访问，是否出现证书或站点错误。 - 账号会话层：当前是否登录正确账号，会话是否被网站要求重新验证。 - 业务操作层：该账号是否有权限，目标记录是否满足操作条件。 ### 把一次访问拆成五个检查点 按顺序记录：客户端是否读取到代理配置、代理地址是否可达、目标域名是否解析、TLS 是否成功、网页是否返回预期业务内容。若最后只有登录页或无权限提示，网络已能到达网页，但业务任务仍未完成；若只有特定网站失败，不要直接重置所有环境的代理。 从同一环境对比一个不含账号数据的公共测试页与目标业务页，并保持其他配置不变。将失败阶段和错误文本留在记录里；代理地址、认证用户名和密码不能放进截图、工单或 AI 提示。 - 配置层：协议类型、主机、端口和认证。 - 连接层：DNS、TCP 与 TLS。 - 应用层：目标页面、登录状态与平台权限。 ### 设置可复现的验收条件 采购或切换前，约定允许测试的地区、访问目标、连接时段、期望页面和代理供应商的服务范围。测速只是某个时间点的链路指标，不代表目标平台稳定、账号合规或页面操作一定成功。记录测试时间与网络环境，避免把一次偶然访问当成长期 SLA。 如果业务需要固定的出口策略，应与供应商服务条款和平台规则一致，并由负责网络的人管理。错误页出现安全挑战时，应暂停并按平台流程处理，不尝试规避验证码或身份验证。 - 测试结果至少含连接成功率、页面可用性和错误阶段。 - 变更后逐个确认代理仍关联到预期环境。 ### 常见问题 **低延迟代理一定更好吗？** 不一定。业务任务还受目标站响应、页面大小、账号权限和本机资源影响，应按实际任务复测。 **代理能隐藏真实 IP 吗？** 目标站通常看到代理出口，但具体取决于代理类型和配置；WebRTC 等其他路径仍可能暴露地址，需要单独检测。 ### 参考资料 - MDN：代理服务器与隧道: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Proxy_servers_and_tunneling - MDN：HTTP Cookie: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies - MDN：代理服务器与隧道: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Proxy_servers_and_tunneling - MDN：HTTP Cookie: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Guides/Cookies --- ## API、固定工作流和 AI 浏览器助手应该怎么选？ URL: https://learn.matrixflow.cn/guides/choose-browser-automation/ 摘要：重复且结构稳定的任务适合明确的工作流；需要理解页面或自然语言目标的任务可以评估 AI 助手；有正式业务 API 时先检查其适用范围。无论采用哪种方式，都需要独立的完成证据和异常停止条件。 ### 核心结论 - 输入稳定、流程固定的任务优先用确定性工作流或 API。 - 需要理解页面或自然语言目标时再评估 AI 助手，不要为简单任务增加不确定性。 - 无论哪种方式，都要求动作证据与业务证据分开。 ### 先看输入是否稳定，再看谁来执行 W3C 的 WebDriver 规范定义了程序控制浏览器的一种接口；执行框架解决如何发出操作，却不会自动定义业务正确性。Playwright 的动作检查会考虑元素是否可见、可操作等条件，但按钮可点击仍不意味着业务已经成功。理解这些边界，才能给自动化设计合适的验收。 以下是 MatrixFlow 团队的决策建议。有明确授权且提供稳定业务接口的场景，先评估 API 的字段、权限与额度。页面路径固定、字段明确的重复任务可评估工作流。页面变化多、指令需要解释时，再评估 AI 助手的观察、规划与结果核验；需要人判断的业务内容保留人工审核。 ### 用一组相同任务做对比 选择三类测试：正常完成、预期失败、提交结果未知。正常任务可以是读取测试店铺的指定记录；预期失败可使用没有权限的测试角色；未知结果可在自有测试系统模拟提交后响应中断。三种方法都按同样条件检查，记录总耗时、人工介入次数、费用与最终结果。不要拿固定脚本的简单演示去对比 AI 的复杂任务。 对多账号任务，额外检查目标环境是否准确、先后顺序是否一致、有没有漏掉中间编号，以及并发任务是否互相干扰。对内容任务，检查事实依据、文本长度、附件和可见范围。样本应覆盖自己经常遇到的工作，不以一次成功推导长期可靠。 ### 把动作证据和业务证据分开 工具维护也要计入选择成本：谁更新页面步骤，谁处理登录失效，谁检查模型输出，失败后如何继续。定时执行还需要安排电脑运行、网络和会话检查。较合适的方案往往让稳定步骤固定下来，让不确定步骤获得足够观察，并为关键写入保留可核验的记录。 这份指南提供选择方法，不是对任何产品的性能排名。网站与业务规则会变化，购买前应索取与自己场景相符的演示和失败案例，再从小范围使用逐步扩大。 - 读取任务：输出字段与页面记录一致，缺失值明确说明。 - 文件任务：文件实际存在、可以打开，内容符合范围。 - 草稿任务：平台列表或详情能读回目标草稿。 - 提交任务：平台状态、记录编号或详情页能独立确认结果；未知结果先核查，不重复提交。 ### 用同一组工作量比较方案 挑选 10 个有代表性的真实任务：稳定的重复读取、需要分支判断的页面操作、多环境顺序任务、长时间等待、结果核验和登录挑战。为每个任务预先写输入、成功条件、失败条件、是否允许写入和人工接管点，再用 API、固定工作流和 AI 助手逐项测量。 比较总完成率、误写次数、漏项、恢复用时、人工介入次数和单次成本。不要只测短演示或把工具自身生成的“成功”作为最终结果；用后台记录、独立页面读回或导出文件作为验收依据。 - 结构稳定且有正式接口：先检查平台 API。 - 步骤固定、分支少：优先确定性工作流。 - 页面变化或意图不清：AI 辅助理解，但设权限与停止条件。 ### 把例外处理和数据边界写进选型 一个适合生产的方案应说明：浏览器会话如何隔离、执行是否抢前台、任务如何取消、步骤日志是否可读、提交结果未知时如何恢复、密钥如何保存、升级后如何回滚。浏览器自动化测试框架可以提供可靠的定位与断言方式，但不会自动理解业务授权或代替平台登录。 先用只读任务验证跨平台安装、无额外运行时依赖、重启恢复和稳定任务顺序；通过后，再对低风险写入做用户授权测试。任何关键检查无法提供证据时，都应作为验收缺口而不是用宣传页补上。 - 把同一任务集保存为固定回归集，每次升级都复跑。 - 对不支持的页面、文件上传和验证场景明确说明。 ### 常见问题 **有官方 API 还需要浏览器自动化吗？** 如果 API 覆盖所需字段与权限，优先 API；浏览器自动化适合 API 未覆盖或必须通过页面的场景。 **怎样对比不同方案？** 用同一组只读任务、相同账号与数据范围测试，比较成功率、耗时、异常可解释性和核验成本。 ### 参考资料 - W3C：WebDriver 规范: https://www.w3.org/TR/webdriver2/ - Playwright：动作可执行性检查: https://playwright.dev/docs/actionability --- ## Canvas 与字体指纹：网站能看到什么？ URL: https://learn.matrixflow.cn/guides/canvas-font-fingerprint/ 摘要：Canvas 指纹来自同一段绘制指令在不同设备、驱动、字体和浏览器实现下产生的像素差异；字体指纹则观察可用字体集合或渲染结果。它们能增加环境特征的区分度，但会受版本、缩放和隐私设置影响，不能单独证明“同一个人”。 ### 核心结论 - Canvas 指纹利用绘制结果的像素差异，字体指纹利用可用字体或渲染差异。 - 它们受显卡、驱动、字体、缩放和浏览器版本影响，是概率性特征，不是唯一身份证。 - 比较两个环境时，应记录版本与条件并重复测试，不要追逐某个检测页的分数。 ### Canvas 指纹怎么产生 网页可以用 Canvas API 绘制文字、图形或渐变，再通过读取像素数据得到一段结果。不同设备的图形驱动、字体栅格化、抗锯齿和浏览器实现，可能让同一段绘制产生细微差异；网站可以把这段结果转换成哈希，作为环境特征之一。 这并不意味着网站能读取你的屏幕或文件。它读取的是浏览器按照指令绘制出来的结果。隐私设置、浏览器版本更新、缩放比例和操作系统变化都可能改变结果，因此同一个设备在不同条件下也可能得到不同值。 ### 字体指纹怎么产生 字体指纹通常通过测量不同字体下文字的宽高、间距或渲染结果，推断设备安装了哪些字体。安装字体集合不同，结果可能不同；但字体版本、替换字体和浏览器限制都会影响判断。 一些浏览器会限制字体枚举或对字体测量做隐私处理，所以检测结果可能因浏览器而异。看到“字体列表”时，要区分真实安装字体与浏览器暴露的近似信息。 ### 为什么不是唯一身份证 因此，不能因为两个环境显示不同哈希就断定它们一定被区分，也不能因为哈希相同就断定不会被关联。指纹是概率性信号，解读时要保留条件与不确定性。 - 碰撞：不同设备可能产生相同或相近的结果。 - 漂移：浏览器升级、驱动更新、缩放变化都会改变结果。 - 随机化：部分浏览器会对 Canvas 结果加入噪声。 - 不完整：指纹只是网站可用信号之一，账号、Cookie、网络和行为也在其中。 ### 对多账号工作的意义 多账号管理关注的是环境特征是否稳定、是否符合目标平台的实际要求，而不是“分数越高越好”。如果环境配置频繁随机变化，可能让同一账号的表现前后不一致；如果所有环境完全一样，也可能降低区分度。 更实际的做法是：固定浏览器版本与配置，记录每个环境的关键特征，在实际目标页面上做只读测试，并观察一段时间内的稳定性。不要用单一检测页的结果替代业务验收。 ### 怎样做一次可重复的观察 观察记录的价值在于可复查。只写“指纹正常”没有信息量；写清版本、条件、结果和未验证范围，才能帮助下一位同事判断是否需要调整。 - 记录浏览器版本、操作系统、屏幕缩放、语言和时区。 - 在同一页面连续读取两次，观察结果是否稳定。 - 关闭重开后再读一次，区分会话变化与环境变化。 - 换一个浏览器版本重复，判断差异来自版本还是配置。 - 保存原始结果与时间，不只保存“通过/不通过”。 ### 常见问题 **Canvas 指纹能唯一识别一台电脑吗？** 不能保证。它可能增加区分度，但会碰撞、漂移，也可能被浏览器随机化。它只是众多信号之一。 **关闭硬件加速会改变指纹吗？** 可能。渲染路径变化会影响 Canvas 和 WebGL 结果，但具体变化取决于浏览器、驱动和页面实现，应实际测试。 **字体装得越多越安全吗？** 不一定。字体集合只是特征之一，刻意堆叠字体也可能造成不一致。更重要的是环境稳定、符合目标平台的实际使用场景。 ### 参考资料 - MDN：Canvas API: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API - MDN：Fingerprinting 术语: https://developer.mozilla.org/en-US/docs/Glossary/Fingerprinting - MatrixFlow 浏览器知识库: https://learn.matrixflow.cn/ --- ## WebRTC 会泄露真实 IP 吗？先分清三类地址 URL: https://learn.matrixflow.cn/guides/webrtc-ip/ 摘要：WebRTC 为建立实时连接会收集候选地址，某些网络和浏览器策略下这些地址可能被页面读取。检测时要把本地地址、公网出口和代理出口分开记录；是否泄露取决于浏览器实现、网络拓扑和策略，不能只凭“已开代理”判断。 ### 核心结论 - WebRTC 可能收集并暴露候选地址，但本地地址、公网地址和代理出口要分开看。 - 是否泄露取决于浏览器实现、网络拓扑和策略，必须实际检测。 - 检测结果要记录浏览器版本、网络条件和时间，不能只看一个 IP 字段。 ### 三类地址先分清 “泄露真实 IP”通常指页面通过 WebRTC 拿到了本不应暴露的公网地址。但私有本地地址、代理出口和中继地址的含义不同，不能混为一个字段。 - 本地地址：设备在局域网中的地址，可能是私有网段，例如 192.168.x.x。 - 公网地址：网络出口在互联网上的地址，目标网站通常看到这个地址。 - 中继地址：TURN 等中继服务分配的地址，用于无法直连时转发媒体。 - 代理出口：使用代理时，目标网站看到的可能是代理服务器地址。 ### 为什么会暴露 WebRTC 建立连接前会收集 ICE 候选地址，包括主机地址、服务器反射地址和中继地址。页面脚本在获得授权或符合浏览器策略时，可能读取这些候选信息。某些浏览器会限制或隐藏本地地址，另一些则可能暴露。 网络结构也会影响结果：直接拨号、路由器 NAT、企业代理、VPN 和双层代理下，候选地址的表现不同。因此，同一个检测页在不同网络里可能给出不同结论。 ### 怎样检测 检测页本身也可能收集数据。选择可信来源，必要时在隔离环境中测试，不要把真实账号和敏感网络信息暴露给不明页面。 - 使用可信的检测页面，记录浏览器版本、操作系统、网络类型和时间。 - 分别在开启和关闭代理的情况下测试，比较公网地址与本地候选地址。 - 检查是否出现 IPv6 地址，以及它是否属于你的真实网络。 - 重复测试两到三次，区分稳定结果与偶发候选。 - 不要安装来源不明的“检测扩展”，也不要把检测结果直接发到公共群。 ### 检测结果怎么解读 如果页面只显示代理出口，说明当前路径下没有看到其他公网候选；如果同时出现真实公网地址，需要检查浏览器策略、代理模式和网络配置。看到私有地址不等于泄露公网 IP，但也不代表环境完全隔离。 IPv6 是常见盲点：代理可能只处理 IPv4，而 IPv6 仍走本地网络。此时页面可能同时看到代理出口和本地 IPv6 地址。 ### 降低暴露的边界 可以通过浏览器策略、网络配置或受控的浏览器环境限制 WebRTC 候选收集，但不同实现的支持范围不同。关闭 WebRTC 可能影响视频会议、在线客服等正常功能，应按业务需要选择。 无论采用哪种方式，都不要承诺“绝对不泄露”。正确做法是：在目标环境中实际检测、记录结果、定期复测，并明确仍未验证的网络与浏览器组合。 ### 常见问题 **用了代理就一定不会泄露真实 IP 吗？** 不一定。WebRTC、IPv6、DNS 或其他网络路径可能绕过代理。需要在具体浏览器和网络条件下检测。 **看到 192.168 开头的地址算泄露吗？** 那是私有局域网地址，通常不能从公网直接访问；但它仍可能暴露网络结构。是否构成风险要结合检测目的判断。 **关闭 WebRTC 会影响正常浏览吗？** 可能影响视频会议、语音通话和部分在线客服。应按业务需要决定，并在关闭后测试目标网站的核心功能。 ### 参考资料 - MDN：WebRTC API: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API - RFC 8445：ICE 协议: https://www.rfc-editor.org/rfc/rfc8445 - MDN：代理服务器与隧道: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Proxy_servers_and_tunneling --- ## User-Agent 与 Client Hints：浏览器如何自我介绍 URL: https://learn.matrixflow.cn/guides/client-hints/ 摘要：User-Agent 是浏览器发送的自我描述，容易被改写且信息日渐简化；Client Hints 让网站按需请求设备、平台和版本等结构化信息。两者都只是环境观察的一部分，修改一个字段不会自动改变 Canvas、字体、网络或账号状态。 ### 核心结论 - UA 是自我描述字符串，容易被改写，也在逐步简化。 - Client Hints 提供更结构化的信息，网站可按需请求，支持范围因浏览器而异。 - 只改 UA 不会改变 Canvas、字体、网络或账号状态，反而可能造成环境不一致。 ### UA 是什么 User-Agent 是浏览器在 HTTP 请求中发送的字符串，通常包含浏览器名称、版本、渲染引擎和操作系统等信息。网站常用它做兼容性判断、统计或内容适配，但它并不是可信身份证明。 由于历史原因，UA 字符串越来越长且充满兼容性标记。浏览器厂商正在推进 UA 缩减与冻结，让字段更稳定、更少泄露细节。不同浏览器和版本的简化程度不同。 ### Client Hints 是什么 Client Hints 通过一组 `Sec-CH-UA` 请求头提供结构化信息，例如品牌、主版本、平台和是否移动设备。部分高熵信息需要网站主动请求，浏览器再决定是否提供。 它的支持范围、默认字段和请求机制因浏览器而异，并非所有网站都使用。把 Client Hints 当作“更准确的 UA”并不完整，它仍然只是浏览器愿意公开的一部分信息。 ### 为什么伪装 UA 不够 环境一致性比单点伪装更重要。一个字段改对了，其他字段仍可能暴露差异；而刻意制造不可能存在的组合，也可能让页面行为异常。 - JavaScript 可以读取 navigator.userAgent、平台、语言等属性，可能与请求头不一致。 - 页面可以通过特性检测判断浏览器实际支持的能力。 - Canvas、字体、WebGL 和网络特征不会因为 UA 改变而改变。 - 版本与平台组合可能自相矛盾，例如声称是移动端却使用桌面字体和屏幕。 ### 对多账号工作的意义 如果业务需要模拟不同设备或地区，应选择真实存在、内部一致的配置组合，并在目标页面上验证语言、时区、屏幕、字体和功能是否匹配。不要为了通过某个检测页而随意拼接 UA。 同时要接受一个事实：平台是否限制账号，不由 UA 单独决定。账号资料、行为、网络和平台规则都在起作用。UA 只是环境描述的一层。 ### 检查清单 检查的目的不是追求“完美指纹”，而是发现明显的不一致和功能问题。对业务来说，能正常、稳定地完成授权工作，比一个漂亮的环境评分更重要。 - 记录请求头中的 UA 与 Sec-CH-UA 字段。 - 记录页面 JS 可见的平台、语言、时区和屏幕信息。 - 检查 UA 声称的平台与字体、屏幕、功能是否矛盾。 - 在目标页面测试核心功能，而不是只看检测页。 - 保存浏览器版本与测试时间，便于复测。 ### 常见问题 **改 UA 能骗过网站吗？** 只能改变部分自我描述，不能改变实际渲染、字体、Canvas 和网络。网站还可以通过特性检测判断真实能力。 **Client Hints 会取代 UA 吗？** 它提供了更结构化的替代方案，但 UA 仍会在一段时间内存在，且不同浏览器支持程度不同。两者可能同时被使用。 **UA 应该和浏览器版本完全一致吗？** 通常应保持内部一致，避免声称的平台、版本与实际能力矛盾。刻意伪造版本可能造成页面功能异常。 ### 参考资料 - MDN：User-Agent 请求头: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent - MDN：Client Hints: https://developer.mozilla.org/en-US/docs/Web/HTTP/Client_hints - MDN：User-Agent Client Hints API: https://developer.mozilla.org/en-US/docs/Web/API/User-Agent_Client_Hints_API --- ## 指纹浏览器能做什么、不能做什么：一张边界清单 URL: https://learn.matrixflow.cn/guides/antidetect-limits/ 摘要：指纹浏览器能提供独立环境、配置管理和一定程度的指纹一致性，但它不能保证账号不被关联、不能替代平台授权、不能消除违规风险，也不能把不真实的经营资料变成可信账号。采购时应要求可复现的隔离与核验演示。 ### 核心结论 - 指纹浏览器提供环境隔离与管理工具，不提供“账号不被关联”的保证。 - 平台授权、经营资料和合规要求不由浏览器软件决定。 - 采购验收要看隔离演示、代理适配、任务证据、日志和故障处理，不只看宣传页。 ### 它能做的三件事 这些能力解决的是“工作空间如何组织”和“环境如何保持一致”，不是“平台一定会如何判断账号”。把工具放回它擅长的范围，才能正确评估价值。 - 组织环境：把不同账号的浏览器配置、Cookie、缓存和存储分开管理。 - 配置一致性：为环境设置语言、时区、屏幕、代理等参数，减少手动重复。 - 协作与自动化：让团队按环境分配工作，并让自动化工具附着到指定环境执行任务。 ### 它不能承诺的五件事 任何“绝对防关联”“永久不封”的说法都无法验证。负责任的供应商会说明适用条件、失败模式和未验证范围，而不是给出无条件承诺。 - 不能保证账号一定不被关联或不被限制。 - 不能替代平台的身份验证、授权和合规审核。 - 不能把不真实的经营资料、内容或交易变成可信业务。 - 不能自动解决代理质量、账号权限和平台规则问题。 - 不能保证所有平台、所有页面、所有动作都被支持。 ### 采购时问什么 要求对方用你的测试场景演示，而不是只看标准 demo。演示后记录版本、条件、步骤和结果，作为验收依据。 - 用两个测试账号演示：分别登录后，关闭重开是否回到各自账号？ - 代理是否真正作用于目标环境？如何证明而不是只看设置页？ - 多环境任务如何指定环境、如何读回每个环境的结果？ - 任务失败、页面变化、登录失效时如何报告和恢复？ - 是否保留操作日志？日志包含哪些字段，如何脱敏？ - 团队权限、环境交接和成员离职如何处理？ ### 验收记录怎么写 一份可信的验收记录至少包含：产品版本、浏览器版本、测试账号、测试页面、操作步骤、预期结果、实际结果、未验证范围和异常。不要只写“通过”或“效果不错”。 对失败项也要记录。失败并不可怕，关键是能否解释原因、是否有替代方案、是否会在你的业务场景中反复出现。 ### 把工具放回工作流 选择指纹浏览器只是多账号工作的一部分。账号资料是否真实、内容是否合规、权限是否清晰、结果是否核验、团队是否交接，都会影响业务结果。工具能降低重复劳动和环境混乱，但不能替代经营与合规。 最实际的评估方式是：用一个小规模、只读、可回滚的任务跑完整链路，从环境创建到结果核验。能稳定完成这条链路的工具，才值得进入更大规模的使用。 ### 常见问题 **指纹浏览器能保证账号安全吗？** 不能。它提供环境隔离工具，账号是否被限制取决于平台规则、账号资料、行为和网络等多种因素。 **环境数量越多越好吗？** 不是。环境数量应与实际账号和职责匹配；过多环境会增加命名、权限、交接和维护成本。 **怎样判断隔离是否真的生效？** 用两个测试账号分别登录，检查页面身份、关闭重开后的状态、Cookie 与本地存储是否互不影响，并记录结果。 ### 参考资料 - MatrixFlow 官方网站: https://matrixflow.cn/ - MDN：Fingerprinting 术语: https://developer.mozilla.org/en-US/docs/Glossary/Fingerprinting - Playwright：浏览器上下文隔离: https://playwright.dev/docs/browser-contexts --- ## 本站常见问题 **浏览器指纹和 Cookie 有什么区别？** Cookie 是网站保存并在请求中带回的数据；浏览器指纹是网站对浏览器环境特征的一组观察。清理 Cookie 不会自动改变指纹，改变环境也不等于网站会忘记已有账号。 **清除 Cookie 就能换账号吗？** 不一定。网站还可能使用本地存储、服务端会话、设备特征和网络信息来判断。清空数据后也可能触发重新登录或额外验证，应按平台正常流程处理。 **指纹浏览器能保证账号不被关联吗？** 不能保证。指纹浏览器提供环境隔离与管理工具，平台如何识别、是否限制账号，由平台规则和实际行为决定。任何“绝对防关联”的承诺都不可验证。 **WebRTC 会泄露真实 IP 吗？** 取决于浏览器实现、网络环境和策略。WebRTC 可能暴露候选地址，因此不能仅凭“用了代理”就假定安全；应在目标浏览器里实际检测并记录结果。 **代理能隐藏所有信息吗？** 不能。代理改变请求经过的网络路径，但不处理 Cookie、本地存储和账号权限；部分代理还可能转发客户端信息。匿名性需要按具体链路判断。 **多开标签页等于隔离账号吗？** 不等于。同一浏览器上下文里的标签通常共享 Cookie 和本地存储。账号隔离需要独立环境或独立浏览器上下文，并应实际检查登录身份是否互不影响。 **指纹检测页分数高就安全吗？** 不能这样推导。检测页只反映该检测方法在当次环境下的结果，不能说明目标平台会如何处理账号。更有价值的记录是具体版本、条件、结果和未验证范围。 **怎样判断一个指纹浏览器是否适合团队？** 看环境组织、账号对应、权限与交接、代理适配、结果核验、日志和故障排查能力。不要只看“防关联”宣传或单个检测页分数。