RPC 的 cookie 谁能读、批量怎么回：比特币核心的 Basic 认证与 HTTP 行为 图 1
RPC 的 cookie 谁能读、批量怎么回：比特币核心的 Basic 认证与 HTTP 行为 · 图 1

用 HTTP 客户端直接调比特币核心的 RPC 时，绕不开一个问题：凭据从哪来。v31.0 的答案写在 src/httprpc.cpp 和 src/rpc/request.cpp 里——默认走的是每次启动随机生成的 cookie 文件，而且服务端只实现了一种认证方案。本文按源码把 cookie 的生成、校验、权限、以及和 rpcauth 的真实共存关系逐项核对，顺带讲清批量请求在 HTTP 层的行为，因为这两个决定经常一起出现在同一个 curl 脚本里。

只认 Basic 的服务端

HTTP RPC 层给 401 应答固定挂一个响应头：Basic realm="jsonrpc"。校验函数先检查 Authorization 头是否以 Basic 开头，不是就一票否决——v31 的实现里没有 Digest 等其他方案的分支。通过 Basic 检查后，把 base64 段解码、按第一个冒号切成用户名和密码，再和当前生效的凭据表比对。比对本身用恒定时间函数做，比对失败还会固定睡 250 毫秒再回 401，源码注释写明这是为了抬高暴力猜测的成本。另外这个端点只接受 POST，GET 会被直接以 405 拒绝，脚本里拿浏览器敲 RPC 端口看到方法不允许，不要误判成认证坏了。

RPC 的 cookie 谁能读、批量怎么回：比特币核心的 Basic 认证与 HTTP 行为 图 2
RPC 的 cookie 谁能读、批量怎么回：比特币核心的 Basic 认证与 HTTP 行为 · 图 2

cookie 文件默认在数据目录下的 .cookie，内容形如 __cookie__: 加一段 32 字节的随机十六进制串，用户名本身就是写死的 __cookie__。每次节点启动都会重新生成，所以把文件内容抄进脚本迟早会失效，正确姿势是运行时读文件拼进 -u 参数：curl --user "$(cat ~/.bitcoin/.cookie)" --data-binary ... http://127.0.0.1:8332/（8332 是主网 RPC 的默认端口）。文件在节点启动时生成并登记进内存凭据表，节点重启换新值后旧凭据自动作废，这是 cookie 相对固定口令的核心优势：凭据的生命周期不会比节点进程更长。

rpccookieperms 与启动校验

默认权限是仅属主可读（源码注释说明经由 umask 0077 达成），同机其他普通用户碰不到它。要放给同组或服务账号读，用 -rpccookieperms=<owner|group|all>；取值不是这三个之一时服务端初始化直接报错退出，这个校验发生在 httprpc.cpp 而不是参数解析层。要清楚放宽的代价：拿到 cookie 文件读取权限的进程等于拿到一个全权限 RPC 会话，多用户机器上 group 或 all 都要有明确理由。RPC 默认只监听本机回环，监听地址与认证方式是两层独立的防线，改 cookie 权限不会把端口暴露到局域网。

与 rpcuser/rpcpassword、rpcauth 的真实关系

源码的分支条件是：-rpcpassword 未设置时走 cookie 生成分支；设置了 rpcpassword 则改用明文配置的 user/password，并额外打一条警告，提示这种用法不如 cookie 或哈希化的 rpcauth 安全。无论走哪个分支，得到的用户名密码最后都会被随机盐加 HMAC-SHA256 哈希后放进同一张内存凭据表；-rpcauth 条目是追加进同一张表的，也就是说 cookie 与 rpcauth 不是互斥开关——设了 rpcauth 时 cookie 照样生成，两种凭据可以同时登录不同会话。想彻底关掉 cookie 文件，用的是 -norpccookiefile，日志会提示 cookie 认证生成被禁用。

批量数组在 HTTP 层的取舍

把多条请求放进顶层 JSON 数组，服务端逐条执行：单条抛错不打断整批，错误对象塞进结果数组，整批统一 HTTP 200 返回——源码注释写明”批量永不抛 HTTP 错误”。没有 id 的通知会被执行但不出现在响应里；整批全是通知时回 204 无响应体；空数组请求回空数组，注释坦承这是为兼容旧客户端而偏离 JSON-RPC 2.0 规范的有意选择。单条请求则看版本：带 jsonrpc 字段的 2.0 请求出错时返回 HTTP 200 加 error 字段，只有旧 1.0/1.1 风格才把错误映射成 400/404 之类的 HTTP 状态码。脚本判断成败要看 JSON 的 error 字段，不能只看 HTTP 状态码。批量也不是事务，前后两条命令之间节点状态照常变化，这点在做余额检查加广播的组合时尤其要注意。

以上边界均以 Bitcoin Core v31.0 源码为准，后续版本可能调整。还要提醒一点：v31 的 RPC 参数面还有 -rpcwhitelist 与 -rpcwhitelistdefault，能给不同用户名挂可调方法白名单，配合 -rpcauth 的多用户哈希凭据使用——批量数组的白名单检查是逐条做的，任何一条越权整批直接 403。本文只讨论节点运维与本机接口使用，不构成任何投资建议。