不开 RPC 认证也能查链：比特币核心 REST 接口能查什么、不能查什么

给比特币节点开一个只读的查询窗口，不配 RPC 认证也能拿区块和链信息——这就是比特币核心自带的 REST 接口。它和 JSON-RPC 用同一个端口，却完全是另一套访问方式：没有命令名，只有 URL 路径；没有参数对象，答案直接编码在路径里。本文按官方文档拆解它的开关、路径清单和与安全边界的误会。

开关与端口

REST 接口默认关闭，用 -rest 选项启用。它复用 JSON-RPC 的端口：主网默认 8332，testnet 为 18332，testnet4 为 48332，signet 为 38332，regtest 为 18443。正因为与 RPC 同端口，一个常见误会必须澄清：REST 是匿名只读接口，不需要用户名密码，但它不等于”可以公网裸奔”——它暴露的是你这台节点的链视图，缓存行为和流量特征也会外泄。

不开 RPC 认证也能查链：比特币核心 REST 接口能查什么、不能查什么图 2 — 不开 RPC 认证也能查链：比特币核心 REST 接口能查什么、不能查什么 · 图 2

路径清单

查询以 .json、.hex 或 .bin 结尾选择输出格式。常用路径包括：GET /rest/tx/[哈希].[格式] 查交易（链上已确认交易需要开启 txindex=1，否则只认内存池里的）；GET /rest/block/[哈希].[格式] 与 GET /rest/block/notxdetails/[哈希].[格式] 查区块；GET /rest/headers/[哈希].[格式]?count=[数量] 拉区块头；GET /rest/blockhashbyheight/[高度].[格式] 按高度反查哈希；GET /rest/chaininfo.json 对应 RPC 里的 getblockchaininfo；GET /rest/deploymentinfo.json 与带区块哈希的变体对应 getdeploymentinfo；内存池有 GET /rest/mempool/info.json 与 GET /rest/mempool/contents.json；UTXO 查询是 GET /rest/getutxos/[TXID]-[N]/.../[格式]，路径里带 checkmempool 还能顺带问内存池状态。

缓存头与一致性

REST 响应默认带 Cache-Control：区块类响应是 public, immutable, max-age=86400，而链状态相关的 chaininfo、mempool、deploymentinfo 等一律 no-store，因为它们会随节点状态变化。官方文档提醒 TTL 故意设得短，避免升级后缓存里留着旧格式的响应；前面架反向代理或 CDN 时要收紧覆盖范围。一致性保证与 JSON-RPC 接口相同——返回的是本节点视角的链尖快照。

一条自检线

部署后先做三条最小验证：第一条，本机 curl http://127.0.0.1:8332/rest/chaininfo.json 能返回 JSON，说明开关与端口对了；第二条，请求一个不存在的哈希，确认返回的是接口自己的错误页而不是连接拒绝——两者的含义完全不同，前者是接口活着，后者是没启用；第三条，对比 /rest/tx/ 查一条已花掉的历史交易，若返回未找到而节点明明同步完成，基本可以断定 txindex 未开。三条跑完，你能准确说出这台节点的 REST 能回答哪几类问题、不能回答哪几类，再决定把它接到什么系统上。

适用与不适用

适合的场景：给内网工具、监控系统、匿名查数提供一个免认证的只读口；配合反向代理做限流和缓存。不适合的场景：任何写操作——它没有写方法；任何要求认证隔离的查询；把它当公网数据服务对外经营。

为什么要有这样一套接口

比特币核心的 JSON-RPC 走的是”方法名加参数对象”的通用协议，而 REST 走的是最朴素的超文本传输语义：任何能发请求的语言、任何缓存中间件、甚至浏览器地址栏，都能直接访问，不需要理解任何比特币特有格式。两种接口的定位因此清晰：写脚本管节点、批量提交数据，用 JSON-RPC；只是把公开链数据拉进仪表盘、静态页面或对拍工具，REST 更省事，还天然享受超文本传输协议层的缓存。也正因为这份省事，官方文档把它描述得很克制——一个补充性的只读视图，不是 RPC 的替代品，更不是服务框架。