先抄下不含秘密的错误码与发生时间，再按错误分类检查。一个错误码可以对应多个原因。
-2015：不是只有“密钥错了”
官方定义涉及 API key、IP 或操作权限。先确认是否选错账户或环境，再检查密钥是否仍有效、工具的实际出口 IP 是否在允许范围、该操作是否被授权。若工具只能笼统显示连接失败，应向其支持渠道索取已脱敏的错误类别。
-1021 与 -1022：时间和签名是两件事
-1021 对应请求时间戳不在接收范围内等时间问题；检查运行工具的服务器时钟，而不只是你浏览器的显示时间。-1022 表示签名无效；工具维护者需要核对算法、密钥匹配和参数编码。不要在公开工单粘贴完整带签名请求。
429：暂停重试，检查请求频率
HTTP 429 表示触发限速。遵守返回的 Retry-After，减少轮询并协调同一出口 IP 下的其他程序。更换密钥不是解决 IP 限制的可靠方法。持续违反限速可能进一步触发 IP 封禁。
把问题交给支持时带什么
提供错误码、UTC 时间、工具版本、正在执行的功能、是否使用测试环境，以及不含秘密的复现步骤。移除密钥、签名、账户标识和私密资产记录。本站的错误选择器只提供检查方向，不替代平台对真实请求的调查。
先确认错误发生在哪一层
“连不上”可能是工具页面打不开、工具没有向平台发出请求、请求到达后被拒绝，或请求有回应但工具无法显示结果。把这些情况混成一个问题，容易在不相关的地方修改权限。先问自己最后一个确定完成的步骤是什么：页面能登录吗，连接配置能保存吗，首次同步开始了吗，有没有具体响应码？
如果只有网页转圈，先记录工具页面的现象，不要声称平台拒绝了密钥。若工具已经给出平台错误码，再进入下面的分类。若支持团队只能提供一个内部编号，请同时询问该编号表示哪一层问题、对应哪个功能和哪个时间，而不是猜测它等于某个官方错误。
工具可能把不同的底层错误合并成同一个提示。你需要的是已脱敏的类别与观察，不是完整网络抓包中的所有内容。对于普通用户，能正确描述发生阶段已经很有帮助；更深入的请求构造问题应由维护相关程序的人处理。
把第一次失败与最近变化放在同一条时间线上
建立一条简短时间线：最后一次确认工作正常的时间，最近一次工具升级或配置变化，第一次观察到失败的时间，以及之后做过哪些尝试。全部统一标注时区。当地时间可以用于个人阅读，但跨团队沟通时再给出 UTC，减少把两个不同事件当成同一次故障的可能。
最近变化不等于已证明原因。它只是优先核查的线索。例如更换服务器后发生问题，可以先询问运行时钟、出口与配置迁移；仍要通过具体结果确认。不要因为时间接近就宣布“平台屏蔽了新服务器”，也不要为了验证猜测同时替换所有设置。
记录失败是否一直发生，还是只在某个功能、某个时段或某次刷新出现。读取一个范围成功而另一个失败，说明现象有边界；这个边界可能比一长串未经处理的日志更有助于服务商找原因。保持描述层面的准确，不把局部成功扩展为整条连接全部正常。
检查访问类问题时，先辨认对象
面对访问类错误，先确认正在编辑的是工具实际使用的那条连接。标签相近、多个环境和旧配置并存时，容易在另一把密钥上修改半天。核对工具里显示的非敏感连接名称与自己的维护记录，不要通过向客服发送完整凭证来确认对象。
接下来分别检查账户实体、环境、密钥是否仍有效、请求的实际运行位置，以及本次操作需要的权限。每项核查都应有依据。云端工具由其服务端发起请求时，家中浏览器的网络信息不能直接说明平台看到的来源。具体地址设置由白名单读本解释，这里先确认你查的是正确的运行地点。
如果某个功能并不在你准备使用的范围内，最合适的处理可能是把它关闭，而不是为它扩大权限。一个只读看板增加自动功能后提示权限不足，不能据此认定原来的只读用途必须授权交易。先找出失败的是哪个动作，才能判断应该修配置还是调整工具功能选择。
时间与签名问题，把维护责任找对
时间问题需要检查实际生成请求的运行环境。你把手机时间改得更准，不一定能改变云端服务器生成的时间戳。给服务商说明是本地程序、自己的服务器还是托管服务，可以帮助确定谁有能力修复。不要让自己在无权管理的系统上反复寻找不存在的设置。
签名问题则需要理解程序怎样构造和签署请求。对非开发者，合理任务是确认使用了文档支持的连接方式、字段没有明显填错，并提供脱敏步骤；不是在公共聊天里试验别人给出的签名脚本。若代码由第三方维护，应要求其根据当前官方规范检查实现与配置匹配。
这两类问题不应靠开放更多账户权限来处理。扩大权限无法解释时间戳为何不被接受，也不能证明签名内容正确。使用对应单点文章找到应收集的证据后，一次验证一个假设，保留结果。别把一次偶然成功当作所有配置已经修复。
限速出现后，先结束无效的重复动作
界面反复点击“重新连接”看起来像是在积极修复，实际可能产生更多请求。遇到明确限速响应时，遵从平台给出的等待信息，并请工具维护者解释自动重试行为。你需要知道停止按钮是否真的停止后台尝试，以及多个连接是否共用运行资源。
不要把不断创建新密钥当成降低请求量的方法。要查清哪些任务在发送、频率来自哪里、是否存在多个副本同时运行。普通用户可以先暂停不必要的刷新和重复任务，再由有权限的维护人员检查请求安排。减少可见页面刷新，不一定等于所有后台请求已减少。
恢复时应观察单一必要功能，而不是同时重启全部任务。如果再次出现限速，把恢复时间和触发功能补进记录，然后回到提供方的正式支持路径。单点读本会讨论重试设计；这里的核心是不要让排错操作持续制造新的错误。
一份脱敏记录怎样既安全又有用
记录可以写成：“工具版本：本次使用版本；环境：正式；功能：只读余额同步；发生时间：指定 UTC 时间；预期：更新已支持范围的余额；实际：返回指定错误码；最近变化：迁移运行服务器；已尝试：按官方说明核对连接对象，未改变其他权限。”它描述的是结构示例，不代表本站发生过这次故障。
不要把账户余额、完整账户标识、API Key、Secret、签名和带秘密的查询串放入公开记录。用文字说明它们已移除。如果删除后错误消息失去含义，可保留字段名称和错误类别，而不是保留真实值。清理完成后再检查一次截图角落、浏览器地址栏、文件名和自动生成的附件。
复现步骤只描述用户可见的最低风险操作。例如打开指定设置页、选择已有连接、发起一次读取检查、看到错误。不要要求他人为了复现去执行真实买卖，也不发送一条可能改变账户状态的完整命令。记录的目的在于让维护者找对代码和配置，而不是复制你的整个账户环境。
什么时候停止自己改配置
如果你已经无法辨认当前有效连接、工具不提供具体错误、或建议涉及你不理解的额外权限，就先停止修改。继续调整会让现象越来越难解释。整理已经发生的变化，向正式支持渠道提出一个明确问题，可以比继续重装更快得到可用答案。
若怀疑凭证已经暴露，优先处理受影响访问，而不是为了保持故障现场让它继续有效。若出现账户异常，按官方支持流程核查。连接诊断与异常处置是不同任务，不能因为还没得到一个确定的技术根因，就延迟收回不再可信的访问。
也有些问题不属于这四个类别。没有匹配错误码时，原样保留已脱敏的提示，查当前官方错误目录或询问服务商。不要强行把每个问题归到你熟悉的一项，也不要因为文章只列四种情况就认为其他情况不可能发生。
修复结论需要包含范围
一次成功读取之后，记录改变了什么、验证了什么，以及还有哪些功能没有检查。若你只修复了测试环境，不把结论写成正式账户已恢复；若只验证一个读取功能，不写成所有任务都可安全重启。清楚的范围能够避免接手者过度解读结果。
把临时调试措施与长期配置分开。检查是否遗留额外日志、重复连接、测试任务或不再需要的授权；根据真实用途恢复应有边界。不要为方便下次排查而把秘密留在共享附件中。最后更新维护记录，让下一次故障有一个明确的已知状态可比较。
如果问题最后由服务商升级解决，可以保存版本与说明链接，但仍只报告自己实际核查的功能。服务商声明修复某问题，与读者自己的环境已经完成验证，是两件事。一个可信的排错记录允许保留尚未确认的部分。
客服让你重新建密钥，先问清哪一步出了问题
可以直接问：“这次收到的是哪个错误码？失败请求用了哪个环境？你们已经检查了哪些配置，为什么判断需要换密钥？”附上出错时间、工具版本和失败的功能即可，不用把密钥或完整签名请求发过去。若对方只能重复“重连试试”，你仍然不知道改动能解决什么。
比如你已核对过账户与环境，而客服怀疑服务器时间偏差，就请负责运行服务器的人确认。你在浏览器上刷新页面，不能替他检查后台时钟。同样，需要核对云端工具的出口 IP 时，应让工具方指出当前使用的地址和对应说明，而不是让你猜一个地址填入。
如果客服给出了具体改动，先弄清影响哪个工具、要不要暂停同步、改完怎样看出新数据已经读到。一次只处理有依据的项目，保留原来的权限范围；没有理由时，不要把更多权限当作修复步骤。回复中可以明确说：“目前只需要读取余额，请按这个用途排查。”
遇到无法解释的账户异常，或发现密钥已泄露，就结束普通的连接排错，按官方安全指引处理。不要继续把可疑密钥放进新的测试网站，也不要付费请陌生人代查账户。