系统是 MacOS M1，和之前的版本一样更新，未对 S3 配置做任何修改，并且其它设备 3.1.16 的版本同步正常，是阿里云的桶。不知道有人遇到一样的问题吗，有解决方案吗？谢谢 ～
相关帖子
优质回帖
-
使命感油然而生，然而我折腾了几天之后还是决定放弃了，我改用 CloudFlare R2 作为主要同步服务器，群晖上用 rclone 定期同步数据做备份。
我的环境：
服务器：群晖 Docker MinIO（还是 24 年中的版本，Docker Hub 被禁用之后我不会升级版本。。。），没有公网 ip 所以选择 CloudFlare Tunnel 做内网穿透。
客户端：MacBookPro Intel 版本，思源 3.1.18。
我的一些观察：
- 我 blame 了一下思源里 S3 获取 Buckets 列表相关的代码，这部分于 2 周前更新了亚马逊的 sdk v2 版本。在亚马逊的 github 里看到 ListBuckets 函数调用了 c 的函数，具体的签名过程我不知道从哪里查看。
- 在 CloudFlare Tunnel 的监听界面里可以获取到访问记录的 http url 和 headers，我对比了 3.1.17 和 3.1.16（iOS）点击“设置”时访问的获取 Buckets 列表操作的记录，发现 url 有比较大的不同，3.1.17 的 url 是
GET https://minioapi.example.com/?x-id=ListBuckets HTTP/1.1，而 3.1.16 则是GET https://minioapi.example.com/ HTTP/1.1；headers 内容略有不同，但其中非常关键的信息是X-Amz-Date（例如20241231T133058Z），这是一个 UTC 时间精确到秒，在相关文档里明确说了这条目是签名认证的关键信息，我用 CloudFlare Rules 调整了一下这个时间果然得到了明确的新的错误信息（格式不正确，或者时间相差太多），但这个条目与我遇到的问题应该没啥关系，因为两个版本发送的 header 里都有它。另一个关键的 header 就是X-Forwarded-For，然而 CloudFlare Rules 里不允许修改这条的内容，因此我无法确认是否因为 CloudFlare 在代理转发过程中篡改了内容导致签名失败。
请输入回帖内容
...
- 其他回帖
-
找到一篇博文， 可能说明了为啥会签名失败：
https://blog.csdn.net/cucgyfjklx/article/details/133165964
大意是通过 Nginx 反代了 MinIO 的服务后会因为 ip 的变更导致前后端计算签名的参数（ip）不一致。
我不是很懂 Nginx 和相关技术，我使用的是 CF 的 Tunnel 方案，也许有类似的问题。
1 回复 -
感谢，试了修改 minio 服务器 Region 为 us-east-1，思源里也同步修改，点击云端同步设置的按钮，依然这个错误：
- operation error S3: ListBuckets, https response error StatusCode: 403, RequestID: 18155F8868F8569E, HostID: dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8, api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method. (Provider: S3)
1 回复 -
使命感油然而生，然而我折腾了几天之后还是决定放弃了，我改用 CloudFlare R2 作为主要同步服务器，群晖上用 rclone 定期同步数据做备份。
我的环境：
服务器：群晖 Docker MinIO（还是 24 年中的版本，Docker Hub 被禁用之后我不会升级版本。。。），没有公网 ip 所以选择 CloudFlare Tunnel 做内网穿透。
客户端：MacBookPro Intel 版本，思源 3.1.18。
我的一些观察：
- 我 blame 了一下思源里 S3 获取 Buckets 列表相关的代码，这部分于 2 周前更新了亚马逊的 sdk v2 版本。在亚马逊的 github 里看到 ListBuckets 函数调用了 c 的函数，具体的签名过程我不知道从哪里查看。
- 在 CloudFlare Tunnel 的监听界面里可以获取到访问记录的 http url 和 headers，我对比了 3.1.17 和 3.1.16（iOS）点击“设置”时访问的获取 Buckets 列表操作的记录，发现 url 有比较大的不同，3.1.17 的 url 是
GET https://minioapi.example.com/?x-id=ListBuckets HTTP/1.1，而 3.1.16 则是GET https://minioapi.example.com/ HTTP/1.1；headers 内容略有不同，但其中非常关键的信息是X-Amz-Date（例如20241231T133058Z），这是一个 UTC 时间精确到秒，在相关文档里明确说了这条目是签名认证的关键信息，我用 CloudFlare Rules 调整了一下这个时间果然得到了明确的新的错误信息（格式不正确，或者时间相差太多），但这个条目与我遇到的问题应该没啥关系，因为两个版本发送的 header 里都有它。另一个关键的 header 就是X-Forwarded-For，然而 CloudFlare Rules 里不允许修改这条的内容，因此我无法确认是否因为 CloudFlare 在代理转发过程中篡改了内容导致签名失败。
1 回复 - 查看全部回帖
