跑了几个月的交易机器人今早突然全线报鉴权错误。第一反应往往是「密钥泄露了」，然后手忙脚乱地删密钥、改代码——而有相当比例的这类故障，源头只是家里宽带被运营商重新分配了一个出口 IP。API 报错的正确姿势是按固定顺序排查，先排除故障，再判断入侵。
理解白名单机制，排查就有了地图。交易所 API 密钥通常由三部分约束：密钥本身（身份）、签名密钥（授权）、绑定的 IP 白名单（位置）。白名单的设计初衷是防「捡钥匙」——就算密钥和签名串一起泄露，不在名单里的机器也用不了。代价是它把服务和你网络的出口地址绑死了：任何让这个出口地址变化的因素，都会让原本正常的密钥「自杀」。常见触发点包括家宽重新拨号后的动态换 IP、光猫重启、运营商基站侧调整、你换了 Wi-Fi 或用手机热点、以及服务器迁移与云厂商的弹性公网 IP 变更。它们的共同特征是：报错突然但集中在某个时间点前后，且你本人恰好动过网络侧的东西。
按这个顺序走。第一步，查出口 IP：在服务器上执行查询自身公网出口地址的命令，例如用 curl 类工具访问一个返回 IP 的服务，对照 API 白名单里配置的地址。变了，就是故障不是泄露——把白名单更新为新出口 IP，或改成更稳妥的固定方案。第二步，查密钥状态：到交易所后台看这把密钥是否还在、权限勾选是否被动过、有效期是否到期自动失效、有没有平台公告的接口变更。第三步，查最近调用记录：多数交易所的 API 管理页能看到密钥的调用与历史，看有没有来自陌生 IP、陌生地域或你未编写过的接口调用。三条里只要出现「你看不懂的调用」，性质立刻从故障切换成泄露。
确认泄露后的处置没有犹豫空间：立即新建一把密钥、只勾选当前业务必需的最小权限（能只读就不开交易，能不开提币就永远别碰提币权限），绑定固定 IP，然后把旧密钥删掉；跑密钥的服务器与代码仓库同步检查，尤其确认密钥没有被提交进公开仓库——提交历史里的密钥不会因删除提交而失效，必须按「已泄露」处理并轮换。如果机器人跑在云上，顺手审计一次云主机的登录记录与计划任务，攻击者拿到服务器后最常见的动作就是就地偷密钥而不是立刻撤离。
两类结构性建议值得采纳。其一，长期运行的服务尽量使用有固定出口 IP 的环境，或者接受运营商的公网固定方案，别把生产脚本架在出口地址会漂移的家宽上；确有移动需求时，为移动场景单独发密钥、单独设名单、到期自动失效。其二，把「密钥」和「能改密钥的账户」分开：日常脚本用 API，而创建、修改、删除密钥的权限只留给带硬件类两步验证的主账户。这样即使脚本人环境失守，攻击者也造不出新的合法钥匙。
补一个常被追问的问题：白名单要不要干脆留空。留空意味着任何 IP 都能用这把密钥，等于放弃了防「钥匙丢失」的最后保险，多数交易所的提示也确实如此。折中做法是按用途拆分密钥：高频调用的只读监控密钥，IP 相对固定，绑定严格；对网络环境敏感的临时任务，单独建一把只有必要权限、设定自动失效时间的密钥，用完即删。千万不要为了省事把一把长期密钥同时用于查询、下单和提现三个场景——提币权限是 API 世界里的核按钮，行业通行实践是 API 层根本不开放提币，若某平台允许，就更要用最严格的白名单和独立的子账户把它隔离起来。另外给所有跑脚本的朋友一条冷建议：把「API 密钥所在的文件路径与权限」也当作安全面来管——密钥文件不进版本库、不进云同步目录、权限收紧到运行账户可读，服务器被入侵的案例分析里，明文密钥躺在默认同步的文档文件夹中，是被「顺手牵走」的头号姿势。
报错不可怕，分不清报错性质才危险。先对 IP，再看权限，最后看调用记录——三步走完，该修网络修网络，该换钥匙换钥匙。本文只讨论运维与密钥管理，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。