默认情况下，一个能通过 RPC 认证的连接，就能调用这个节点上所有可用的 RPC 方法。-rpcwhitelist 和 -rpcwhitelistdefault 用来收紧这件事：给不同 RPC 用户各配一张”只能调这些方法”的清单。两条参数都定义在 src/init.cpp 的 RPC 类目里，实现的是按用户过滤传入调用的一层闸。
清单怎么写
-rpcwhitelist 的取值格式是 <用户名>:<方法1>,<方法2>,…，用一个用户名加一列逗号分隔的方法名，声明这个用户被允许调用哪些方法。它可以写多次；如果对同一个用户设了多条白名单，最终生效的是它们的交集——只有同时出现在多条清单里的方法才放行。这样设计方便你把权限拆成几段策略叠加，但叠加结果是”越写越窄”，写的时候要对齐交集语义，别指望多条取并集来放宽权限。
默认行为由 -rpcwhitelistdefault 定
这条参数控制”没有明确写清单的用户/方法怎么处理”。帮助文本给出的规则是：只要 -rpcwhitelistdefault 没被设成 0，那么只要你给系统里任何一个用户设了 -rpcwhitelist，服务器就会把所有用户都当作”未被特别指定就等于空白名单”来对待；而如果把 rpcwhitelistdefault 设成 1 且一条 -rpcwhitelist 都没配，那么所有用户都会被当作空清单——等于把所有 RPC 调用都拒掉。这段语义有点反直觉，核心是”清单一旦启用，默认从严”，未列入的一律不可用，除非你显式改默认。
它解决什么威胁模型
RPC 面一旦暴露，拿到认证凭据就等同于拿到节点的全部控制力。白名单让你能给不同用途发不同权限的凭据：给监控脚本一个只读类方法的用户，给某个只想要钱包发送功能的服务一个最小方法集，把危险的管理类、调试类方法排除在外。即便某个低权限凭据泄露，攻击者能调的方法也被清单框死，缩小了爆炸半径。它和 rpcauth 是配合关系：rpcauth 管”你是谁、能不能进门”，rpcwhitelist 管”进门之后你能开哪些门”。
用错最容易翻的两点
一是把默认语义想反：局部启用白名单会把所有用户拖进”不在清单即拒绝”的状态，若你没给某个正常用途单独配全方法，它会突然调不动任何 RPC。二是方法名要靠准确：白名单按方法名精确匹配，名字写漏或写错，对应功能就被挡在外面，表现为原本正常的调用被拒。上线路径建议：先在测试节点上按每个用户逐一列清它实际需要的方法集，用一台功能机验证每个脚本都能跑通，再上生产；并清楚知道改配置、重启后白名单才生效。它只影响 RPC 入口面的权限，不碰 P2P 中继、共识和钱包资金逻辑本身。
与 rpcauth 的配合姿势
-rpcauth 用”用户名加两个随机十六进制串（salt 与 SCRAM 风格 verifier）“的形式替代明文用户名密码，凭据文件里不落明文口令；白名单则建立在这套用户体系之上，两者在配置文件里逐用户搭配：先给每个用途发独立用户名，再给每个用户名挂各自的清单。工程上常见的分层是监控用户只挂链状态与网络信息类只读方法，对账服务再加钱包余额查询，管理类方法谁都不给。还要留意批量调用的检查粒度：JSON-RPC 批量数组里每一条都独立过白名单，任何一条越权会让整批请求直接被拒——脚本若习惯把多条调用打包发送，上线白名单后要先逐条自查方法集，否则会以”整批 403”的形态暴露问题。被拒调用返回方法不允许类错误，日志里可定位是哪个用户越了哪条线，方便按脚本清单逐项补齐。白名单与 rpcauth 都是配置文件层面的开关，改动需重启生效；具体引入版本以官方版本说明与源码历史为准。本文讨论 RPC 权限面配置，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。