Remotely-Save插件同步失败问题分析与解决方案

问题现象

用户在使用Remotely-Save插件（版本0.5.21）与MinIO对象存储进行同步时，系统报错提示同步失败。从错误截图来看，虽然文件实际上传到了存储桶，但客户端仍收到了错误响应。

环境配置

• 操作系统：Linux
• 云存储服务：自建MinIO（S3兼容）
• Obsidian版本：1.6.7
• 网络架构：使用内容分发网络管理域名

根本原因分析

经过深入排查，发现问题源于内容分发网络的缓存机制。当插件向MinIO端点发送请求时：

1. 认证头信息被内容分发网络缓存
2. 后续请求使用缓存的认证信息
3. 由于S3协议要求每次请求都需要新的签名认证，缓存导致认证失效

解决方案

针对该问题，建议采取以下措施：

1. 内容分发网络缓存规则配置 在控制台中为S3端点URL设置缓存绕过规则：

• 创建Page Rule
• 匹配模式设置为s3.yourdomain.com/*
• 设置缓存级别为"Bypass Cache"

2. 替代方案 如果无法修改CDN配置：

• 直接使用MinIO的IP地址或内部域名
• 在本地hosts文件中绑定MinIO服务地址
• 考虑关闭内容分发网络的代理模式（灰色云图标）

技术原理补充

S3协议要求每个请求都必须包含由访问密钥、请求内容和时间戳生成的签名。这个签名具有时效性（通常15分钟），因此：

• 缓存认证头会导致后续请求使用过期签名
• MinIO服务端会拒绝这些无效请求
• 虽然文件可能上传成功，但客户端无法获取正确响应

最佳实践建议

1. 对于API类端点，建议全局禁用CDN缓存
2. 敏感操作接口应当设置Cache-Control: no-store头
3. 生产环境建议为API和静态资源使用不同子域名
4. 定期检查CDN的缓存规则是否影响业务逻辑

总结

该案例展示了基础设施组件（如CDN）与应用协议（如S3）之间的微妙交互问题。开发者在集成云存储服务时，需要特别注意中间件对协议特性的影响，特别是涉及认证和签名的场景。通过合理配置网络架构，可以避免这类"看似成功实则失败"的边界情况。