系统是 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 在代理转发过程中篡改了内容导致签名失败。
请输入回帖内容
...
-
+1 求助
可以了，Regoin 我的改 oss 地域 ID 可以了 https://help.aliyun.com/zh/oss/user-guide/regions-and-endpoints?utm_source=ld246.commuweize • -
+1，我的是自家的 minio S3，地区我自己填的 zh_cn，之前只要服务器和客户端能对上就行，更新之后的提示和你的一样。
更新之前还测试过可以同步，更新后马上就失效了。
1 回复minio 和思源都改成 cn-beijing 之后还是有报错： operation error S3: ListBuckets, https response error StatusCode: 403, RequestID: 18155E8E4B17xxxx, HostID: dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2xxxx, api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method. (Provider: S3)Whacka • -
感谢，试了修改 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 回复 -
-
感谢回复。试了一下换成 virtual-hosted-style，还是不行。我又重新生成了一个 key，还是出现同样的错误。。。
operation error S3: ListBuckets, https response error StatusCode: 403, RequestID: 1815ED86DD66ED94, 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)
我感觉应该是 Secret key 没有被正确传进去，毕竟配置不变，降级成 3.1.16 就完全没问题
1 回复 -
找到一篇博文， 可能说明了为啥会签名失败：
https://blog.csdn.net/cucgyfjklx/article/details/133165964
大意是通过 Nginx 反代了 MinIO 的服务后会因为 ip 的变更导致前后端计算签名的参数（ip）不一致。
我不是很懂 Nginx 和相关技术，我使用的是 CF 的 Tunnel 方案，也许有类似的问题。
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 回复 -
- X-Amz-Date 这个应该是参与到签名计算过程中，时间不一样签名肯定不一致，除非 CF 不缓存，关闭小黄云；但大家开启小黄云是有自己的应用场景的，比如我是办公场所没有 IPV6 环境，家里没有 IPV4 公网 IP，所以需要 CF 代理一下，关闭小黄云直接连接不了了；
- X-Forwarded-For 之类报文头，需要付费计划才能在规则里修改；由于上边时间不一致，估计也不管用；
- CF 官方抢到了 cloud connecter 服务，我看了看，主要是连接 S3 的，但只支持自家和亚马孙、微软、谷歌。想必 CF 官方也清楚 CDN 不能支持 S3 V4 版本的代理，所以才推出了云直联服务；
- 解决办法：
- 继续用 16 版本，在版本没有大变化前提，能继续用一段时间；
- 家里 NAS 想办法获得公网 IPV4，不用 CF 代理改用直联；
- 改用公网云服务，阿里、腾讯、七牛或其它；
- 改用 docker 自建的 siyuan，远程访问网页版，虽然 CF 代理影响 S3 同步，但不影响纯网页的浏览。🎉
-
不太死心，研究了几天之后还是失败了，但了解到了一些信息，作为成果讨论一下，由于和本帖的问题不太一样，单独开了一帖：
v3.1.17 或更高版本通过 CloudFlare Tunnel 访问 MinIO S3 提示 SignatureMismatch 问题的一些研究
请输入回帖内容
...
