钱包请求被浏览器拦下：CORS、混合内容与扩展拦截的排查分诊法

网页钱包发起请求没动静、交易状态卡在空白页、控制台一片红——网页与节点之间的对话有时根本没出发，而是被浏览器扣在了本地。这类故障不来自链，也不来自钱包，排查思路要整个换一套：先怀疑你与节点之间的“网页规则”，而不是区块链本身。

浏览器会替你拦下哪些请求

最经典的一关是同源策略下的跨源限制（CORS）。浏览器规定：一个源（协议加域名加端口）的脚本要向另一个源发请求，必须由服务端通过响应头声明允许哪些源，浏览器才会放行；对某些带自定义头的请求，浏览器还会先发一个预检请求试探服务端态度。RPC 节点面向网页提供服务时，若节点配置里没有把该网页所在的域名列入允许来源，或反代、CDN 中间层把关键响应头剥掉了，你在页面上看到的就是“点什么都没反应”，而真实报错躺在开发者工具的控制台里，关键词是 CORS 或 Access-Control。它与密钥、与账户、与链全部无关——修好节点配置或换节点即可。

另一关是混合内容限制：HTTPS 页面加载脚本时若去请求明文 HTTP 接口，浏览器会拦截被动内容甚至直接阻止脚本发起的请求。许多“网页钱包连不上节点”的案例，实际是节点地址写成了 HTTP 前缀、或某个中间跳转把安全连接降级。自查方法很直接：把 RPC 地址复制出来看前缀，HTTPS 页面配 HTTPS 接口才是可长期工作的组合。证书链不完整、系统时间严重偏差造成的 TLS 失败也属此类——证书校验对时间敏感，时间错乱时先校准系统时间再谈其他。

还有一关来自扩展与安全软件：内容拦截器、隐私插件、企业网关的过滤规则可能把发往节点域名的请求直接掐掉，或注入脚本改写了页面的网络调用。特征是同一个网页在另一台设备或移动数据网络下正常。逐一停用插件复现、比对网络面板里请求是被阻止（blocked）还是发出后失败，是两种完全不同的结论。同理，浏览器自带的“增强安全浏览”、DNS 过滤服务（家庭守护、广告过滤型 DNS）也会按名单拦截被标记的域名，这类拦截在本机日志里往往显示为一行“已阻止”，比 CORS 报错更隐蔽——被拦的页面看起来只是一片空白。

分诊顺序：先定界，再修

第一步换参照物：把地址、交易哈希拿到区块浏览器直查。浏览器查得到而网页应用显示不出，故障锁定在该网页到节点的通路；浏览器同样查不到，才回到钱包、签名、广播那条链路上排查。第二步开开发者工具的网络面板重新触发操作，看请求三要素——有没有发出（not sent）、状态码是什么（通道问题看 HTTP 码）、控制台是否报 CORS 或混合内容字样（本地策略问题）。第三步对症下药：CORS 报错换提供正确响应头的节点或换官方推荐域名；证书告警检查地址栏与安全连接指示，绝不点“继续访问”；请求被扩展拦截则按扩展逐个排除。

最后划一条安全边界：以上全部属于“通道修不通”的故障，没有任何一种需要通过交出私钥、助记词或在陌生页面签名来修复。修网络问题的正确姿势永远是换通道、查规则、找官方入口，而不是换一种更危险的方式把账户暴露出去。

本文不构成投资建议；连接类故障的排查全部在通道与规则层面完成，不需要也不应该通过交出密钥来修复。