先固定查询坐标，再谈“协议栈哪一层”
检索“区块链协议栈”遇到查询失败，常见把页面红字、网关超时和节点 JSON-RPC 错误混成一句“链挂了”。定位时应先记录：请求时间、所选网络/端点、方法名（如 eth_getBalance）、块参数（latest/safe/finalized/pending 等）以及原始错误码或返回体。
ethereum.org 的 JSON-RPC API 文档说明执行客户端以 JSON-RPC 对外提供接口，并单独解释 block 参数可用 latest、safe、finalized、pending 等字符串；示例还提示 curl 的 Content-Type 不匹配时节点可能返回与业务无关的报错。说明“同名方法”仍可能因参数或编码约定失败。
传输层：HTTPS/TLS 报错不等于 RPC 业务错误
MDN 的 Transport Layer Security 页指出：TLS 使客户端与服务器在不可信网络上安全通信，用于保护 HTTP 即 HTTPS；并以加密、身份认证等方式保护连接。网页若在证书、混合内容或握手阶段失败，失败点在传输/浏览器安全策略，尚未进入节点的 JSON-RPC 方法分发。
因此应先确认 URL 是否 HTTPS、证书是否由宿主正确配置，再把响应体当作 RPC 结果解析。把 TLS 中断写成“nonce too low”或“节点拒绝该方法”，属于层级错位。
节点层：读回执，不读营销文案
当 HTTPS 已成功且收到 JSON-RPC 回执，再根据 error 对象或结果字段判断是方法不支持、参数非法还是状态不可用。邻篇关于 nonce 或钱包接口的讨论处理的是具体错误码场景；本篇固定在“网页展示 / 传输 / RPC”三层定位，不提供绕过限流、伪造回执或攻击节点的方法。
只读排查可以停止在：复现同一方法与块参数、对比另一可信端点、保存原始请求与响应。不要在未验证的情况下改写交易或重放。
核对边界
可记录：时间、网络、方法、块参数、HTTP/TLS 是否成功、JSON-RPC 错误码。不可记录：攻击或规避限流步骤、伪造节点响应、投资或交易指令。