首页能打开，登录却一直转圈，常见的排查误区是继续反复检测首页。现代网站的登录流程可能经过身份服务、API、脚本资源和第三方跳转；首页可用只证明其中一步。应该先找出哪个必要请求没有完成，再把浏览器证据、域名检测和应用日志对齐。
本篇适用于自己管理或获准排查的网站。WeaveBit 可以补充依赖域名在中国大陆的网络观测，不会替你登录、执行 JavaScript 或验证完整业务流程。整个网站都打不开时，可先读访问异常排障指南。
1. 把“登录失败”改写成一个具体步骤
先区分登录页打不开、点击按钮没有反应、认证请求失败、跳转后没有登录状态，还是登录成功后数据加载失败。记录失败发生的时间和时区、用户所在地区与运营商、宽带或移动网络、浏览器版本，以及代理或企业网关是否参与访问。
用受控测试环境和测试账户复现一次即可；不要为排障连续提交订单、付款或重复触发邮件、短信。比较“已登录”和“未登录”时，也要注明账户状态，否则两次访问可能根本没有执行同一组请求。
2. 在浏览器中找到没有完成的请求
在操作前打开开发者工具的 Network 面板，清空旧记录；登录会跳转时启用 Preserve log，然后执行一次获准的正常操作。先看 Fetch/XHR，再检查相关 JS 请求。查看失败行的 Status 和 Initiator，追溯发起它的脚本或跳转。操作位置可参考Chrome 官方 Network 文档。
不要只盯红色行：长时间等待的请求、未加载的登录脚本也可能使按钮失效。如果根本没有发出认证请求，先查看浏览器 Console 的脚本错误和资源加载情况。记录最早影响该步骤的异常，避免把后续连锁失败全部当成独立故障。
3. 分清请求来源、目标域名和业务路径
在自己的受控环境中核对请求的实际目标：协议、主机名、端口和路径；若有重定向，也检查最终目标。页面地址是 www.example.com，不意味着认证请求仍发往这个域名。浏览器的 origin 由协议、主机和端口共同确定；请求头中的 Origin 通常描述发起请求的来源，不是目标主机。
路径能帮助区分登录、刷新会话和获取账户数据，但域名检测不能复现路径上的接口操作。对外记录路径时，去掉查询参数、用户标识和令牌；例如只留下 /session 这样的无敏感信息模板。不要直接复制完整请求 URL 或请求头到工单。
4. 按证据类型分派，而不是统一叫“被墙”
| 浏览器观察 | 优先核对 |
|---|---|
| 请求失败，没有可用 HTTP 响应 | 实际目标域名、连接错误、用户网络与同时间域名检测；保留未知原因。 |
| 401、403 或 5xx | 认证、访问策略及应用/CDN 日志；收到状态码不代表登录成功。 |
| CORS 提示或预检失败 | Console 详情、相关响应与跨源配置，不以关闭浏览器安全限制解决。 |
| API 有响应，页面仍无法继续 | 业务错误、脚本处理、会话状态及后续依赖。 |
CORS 控制浏览器如何允许跨源脚本请求；仅看到一个 CORS 提示，不能确定是网络原因还是响应配置问题。相关概念见MDN 的 CORS 说明。身份认证与访问错误的含义可核对HTTP 状态参考，再结合自己的日志判断。
5. 把实际依赖整理成有优先级的清单
为实际访问到的主机分别标注用途、负责人、是否必需及检测授权：登录 API 和认证脚本可能直接决定业务能否继续；统计或装饰性图片失败未必阻断登录。第三方验证码、身份服务或支付服务是否属于关键依赖，要依据真实调用关系，不靠域名名称猜测。
只把自己管理或有权检测的目标加入 WeaveBit 清单，输入纯域名，去掉协议、路径、端口和重复项。第三方域名可以先记录责任方和已有浏览器观察；不要把页面出现的所有第三方主机自动批量扫描。扩展检测前先确认授权与供应商允许的诊断范围。
6. 用域名观测补齐浏览器记录
单个获准目标需要初步 DNS 污染观测时，可使用免费 DNS 污染检测。没有报告污染，不等于认证接口可用；异常也不直接解释账户为什么登录失败。对多域名或 HTTP、HTTPS 相关问题，可以直接使用 GFW 全量，不必先逐个检测 DNS。
GFW 全量包含 DNS 污染、HTTP Host、TLS SNI 三个维度及汇总，并非全部检测方法或完整浏览器测试。按实际用户网络选择相关 GFW 节点，保留时间和分项状态。DNS 污染检测不需要用户选择节点。端口、输入与操作入口见全量检测指南；正常、异常与无法判定应按结果文档分别保留。
7. 示例：先查登录 API，而不是扩大首页检测
以下是虚构示例，不是真实客户案例：www.example.com 首页加载成功，登录依赖 api.example.com，认证脚本来自 assets.example.com。浏览器显示脚本已加载，认证请求未获得可用响应。团队在拥有检测授权的前提下，将 API 域名列为优先目标，并在自己的应用日志中核对同一时间。
若相关 GFW 观测也异常，保留这一网络证据继续调查；若观测正常，则继续核对用户网络、真实接口请求和服务器策略。若为无法判定，记录待确认并复查。任何一种结果都不直接证明密码错误、登录恢复或根因已找到。
8. 交接最小记录，并保护诊断数据
只手工整理必要字段：受影响步骤、带时区的时间、地区与运营商、获准目标的域名与端口、脱敏路径模板、错误类别或状态码、发起组件摘要、相关检测的时间与状态、下一步负责人。逐项去掉 Cookie、Authorization、API Key、密码、验证码、查询令牌、账户与订单信息。
不要共享原始 HAR、请求回放命令或整段请求头。Chrome 的sanitized HAR 说明列出了排除的部分敏感头，但 URL、请求体或响应内容仍可能带有业务秘密和个人数据；它不是可直接公开的文件。保留经过人工复核的最小文字记录，截图也应遮去地址参数和个人信息。
登录、API 和资源域名稳定后，可从Console 入口为关键目标配置持续监控，并参考任务与告警指南。网络结果应与应用告警一起交给负责人，而不是代替最终登录验证。