常见问题
原版服务器可以使用吗
可以使用默认的普通聊天传输，不需要服务端安装模组或插件。双方都需安装客户端模组并导入公钥。自定义载荷共享和开发 API 需要兼容中继。
为什么发送了消息，对方没有收到
按顺序检查：
- 双方是否导入了正确的公钥，名称和信任状态是否匹配。使用
/k04m key list、/k04m status <player>和完整指纹核对。 - 是否选中了可用传输。原版服务器请用
CHAT；CUSTOM_PAYLOAD需要服务端广告对应通道，不会自动回退。 etell是否已有有效会话。尝试/k04m session list或/k04m session refresh <player>。- 是否刚断线或切换服务器。排队的聊天片段会取消。
- 是否存在聊天过滤、签名、速率限制或反垃圾插件。大包需要分片，可能超时或被丢弃。
- 是否通过系统消息接收中继片段。检查 Shadow Listen 与表达式，并使用
stell或建立会话后的etell。
服务端有中继，为什么仍然被聊天垃圾检测踢出
聊天垃圾检测绕过需要启用且兼容的 ProtocolLib。没有它，普通聊天中继和自定义载荷仍可工作，但无法提供这项绕过。
kick-krypt04mcg-chat-spam: false 表示不让 Krypt04Mcg 片段计入该踢出机制；设为 true 才使用普通垃圾检测行为。README 明确指出 ProtocolLib 在 26.3 上的包拦截尚未验证，不能因为安装成功就假设该功能可用。
改了算法，为什么公钥没有变化
设置只在首次生成或显式重新生成密钥时应用。已有密钥不会被配置静默覆盖。请按重新生成流程操作，并通知所有通信对象更新公钥和验证指纹。
密钥变化提示可以直接忽略吗
先通过可信渠道确认是否为对方主动轮换、换账号或其他预期操作。TOFU 拒绝覆盖是为了暴露身份变化。确认后显式删除旧记录、导入新记录并重新验证，不要只为消除提示而盲目信任。
tell、stell、etell 有什么区别
tell 是长期 KEM 加密且未签名；stell 在长期 KEM 加密之外附带签名；etell 使用签名握手建立的会话，逐条消息用 AEAD 认证。会话协议 v4 不接受旧 v1–v3 会话消息，双方都必须更新。参阅命令参考。
文件共享或 API 为什么不可用
确认双方已导入公钥、对应开关已启用，且服务端广告了兼容通道。文件发送与接收各有独立开关，默认关闭；公共 API 另由 enableDataApi 控制。
当前客户端的加密流 API 已替换旧 DATA/ACK/NACK 传输。插件保留旧通道，不代表新客户端会使用它们。以所选客户端和插件版本的协议能力为准。
为什么通道数量改了还没生效
客户端更改 apiChannelCount 后需要重启；服务端配置是 api-channel-count，重载会中止活动流。槽位由服务端所有玩家共享，而且需被两位客户端同时订阅。
能保证聊天内容和身份信息完全隐藏吗
不能。服务端依然能看到路由所需的玩家身份、接收者和流量特征；默认聊天还可能把加密片段广播给其他玩家。项目未经过独立安全审计，没有可以承诺的生产级保密性。参阅安全与限制。
在哪里反馈问题
客户端问题提交到 Krypt04Mcg Issues，中继问题提交到 插件 Issues。说明客户端/服务端版本、加载器、传输模式和复现步骤。公开反馈中不要包含私钥、存储主密钥或敏感聊天内容。