该内容就当作是过程的记录，评论区有大佬欢迎补充。
先把我这边的情况放在前面：我的浏览器默认开着 WebRTC Control这个插件，不了解的可以稍微问问ai。
我的邀请码：CH1MP5
故事开始传个一张图片， 然后试着自己F12找找原因。
我用的是 Windows 和 Chrome。最开始从文件夹拖图片到 Muse，附件明明已经出现在输入框里，发送就是失败。后来试了左侧的 + 按钮，手动选文件，也遇到过同样的问题。
偏偏它还不是每次都失败。有时候按 Win + Shift + S 截个图，再 Ctrl + V 粘贴进去，就能发出去；过一会儿再试，又不行了。
如果一直失败，至少还能慢慢排查。最烦的是这种时好时坏：刚觉得自己找到办法，下一张图就把这个结论推翻了。
我先让 ChatGPT 帮忙找了公开讨论和相关资料，想看看是不是大家都在遇到。当时那轮检索里，没有找到足以确认“网页端图片上传普遍故障”的官方公告。
倒是在一份第三方保存的客户端文档镜像里看到了文件说明：聊天框支持选文件、拖拽和粘贴，文档还提到粘贴图片约 8 MB 的限制，以及 HEIC、AVIF 上传时转成 JPEG 的处理。这不是官方故障说明，也未必对应当前版本。我实际拖 HEIC 进去还是报错，所以最后只能把它当作参考，不能当作“这功能肯定没问题”的证据。
接着打开了 F12。Console 一片红，看着挺吓人，主要有这两类：
net::ERR_BLOCKED_BY_CLIENT
[HatchChat] chat.stream send failed
图片这里暂时就不传了因为和内容关系不大，看字也能看懂
第一类不少出现在 /monitoring 请求上。当时怀疑过广告拦截或隐私插件，但也可能只是监控请求被挡了，和图片发送失败不是同一件事。第二类倒是直接对应发送失败，只是光看这行，也看不出究竟卡在附件处理、连接还是服务端。
Network 里又找了半天“WS”，才发现我这版 Chrome 显示的是 Socket。开启保留日志、刷新后重新发图，能看到类似 noise?vm_id=... 的连接，状态是 101。
我一开始还以为 101 说明连接没问题，那图片应该也发出去了。后来才搞清楚：它只是 WebSocket 握手成功，和附件是否上传、消息是否被确认收到，是两回事。
另外看了一份第三方的 Muse-Chat-MCP 通信研究，里面提到了 chat.stream 和加密 WebSocket。这也解释了为什么只盯着普通 Fetch/XHR 或一个 101 状态码，很难直接看出发送卡在哪里。到这里其实还是没敢从这方面判断。。
然后换节点，关插件
当时Chrome 里开着 WebRTC Control。
原节点下，文字能发，图片失败。换节点之后，文字和图片曾经都发成功了。我当时真的以为修好了，结果后来拖本地文件还是失败过，手动选文件也一样。
再试 WebRTC Control 的开关，上传表现也有变化。于是问题更麻烦了：节点像是有影响，插件也像是有影响，但没有哪个操作能保证后面一直正常。
WebSocket 和 WebRTC 本来就不是一回事。这个插件到底动了哪个环节，
搞半天结果还有 HEIC
后来我才注意到，之前测试用的部分图片来自 iPhone，原始格式是 HEIC。
这点真的挺奇怪，官方文件我记得是支持自动转换格式的，但是不知道为什么没有生效。。。。
总结
折腾完这一轮，我觉得不妨按接下来几点考虑
- 记得关了你的WebRTC插件
- 换换节点
- 拿一张小体积、真正的 PNG 或 JPG 测试。HEIC 要实际转换编码，别只改后缀。
至于是不是 Muse 的通用 HEIC 处理问题、某些出口 IP 的限制，或者插件具体和哪个环节冲突，我不敢确定。
如果你也遇到“图片选进去了，发送却未送达”，可以说说浏览器、节点地区、图片格式，以及哪种添加方式成功过或者你们是怎么解决的。反正目前看来网页端还是有些问题在的。
使用环境：Windows、Chrome、Muse 网页端、WebRTC Control。