早些年获得腾讯云EdgeOne试用资格的时候，体验过一番，对加速上来说却是是非常方便的，只要在所有服务的最前端设置好规则就可以全站加速，当然也有一些比较麻烦的事情，比如IP变动、动态控制缓存没有那么灵活，如果要批量使得动态路由缓存失效追溯起来有些许困难。最近在结合 Termux（手机linux端） + Openlist 时，就出现了意料之外的错误，虽然说EO不应该背这个锅，但是让我脑力消耗了不少，还是被我无情的推做替罪羊了。

起因

    一切的开端源于服务器上Openlist建好后，开始不断的利用Openlist，做各项自动化任务集成。

    就比如说，我有定期备份手机照片的习惯，之前是通过连接USB，然后手动拷贝到移动硬盘进行一级备份，然后同步到云端NAS上二级备份，虽然只需要简单一二步，但是还是有些麻烦。尽管手机品牌方给了5G的免费空间，也依然无法遭得住日益增长的数据冲入，很快的，手机品牌就提示云空间不足，要我充钱买更大的空间了。技术出生的我，怎能让他得逞，所以准备想办法让手机直接连上我的Openlist，进行自动上传。

    技术上的选型在文章开头就已经描述了，手机端使用Termux程序，一个linux终端，服务器部署Openlist，通过webdav规则进行数据交换，数据交换工具使用Rclone。这些技术在之前的文章都有所提及，这里不多赘述，简单串联起来就可以明白其中方法了。

经过

    起先，一切都非常顺利，rclone正在以满速将本地图片数据写入到服务器，很快的几乎全部的图片都已经同步成功了。看到计划顺利进行中，别提有多高兴了。

    过程中，有一个文件上传报了错，一开始也没多想，直接重跑rclone copy，毕竟Rclone是增量机制的，不用担心重复数据。但是重试了三次依然失败，仔细一看，原来是报了413错误了，害，不过是忘记在服务器配置 NGINX 的 clientbody 大小罢了，睡一觉明天配置下就好了。

    第二天......

    很大方的给 client_max_body_size 设置到了 5G，并且nginx -s reload多次确保成功，我想着，这下准没问题。非常期待的执行了rclone命令 rclone copy img openlist:Girls --buffer-size 8M --progress 。结果~

    斯，怎么还是413，难道是配置的不对？又参考AI，多配置了一些乱七八糟的参数，尝试了各种配置方式都以失败告终。难道说是Openlist应用层本身做了限制？为了查看是否有限制，在官方文档翻阅了所有可能的说明，都没找到，在配置文件中翻来覆去的找size字段，倒是也有size，不过是log的size无关紧要。

    那么验证的唯一方法就是、绕过NGINX，直接把请求打到Openlist上，所以就直接用IP:PORT的方式进行访问，而不走NGINX代理了，结果是——上传非常流畅，没有任何卡顿。所以可以验证和OpenList完全无关，OpenList没有做任何的限制。

    不是OpenList的问题，也不是Nginx的问题，难道是域名有问题？于是乎，我将OpenList服务挂到了我的测试域名上，结果，居然真的顺利跑通了！

    仔细想了一伙儿，才想到了这个域名我好像做了EdgeOne加速服务，或许是命中了之前的缓存了？查看了下webdav的请求，发现都是Rest风格的，文件路径和名称直接拼在了基础路径上，请求通过PUT、COPY、GET等方式发送，这就导致了很多压缩包、图片、视频的请求击中了EO缓存（设置的缓存7天，毕竟当时想的是Openlist里图片也不怎么变动，存久一点随时快速看），一直返回413错误，从未正常传输过。

结果

    鉴于此，把openlist域挂载的EO服务先撤掉，然后DNS重新指向原站，等待刷新后，重跑clone指令。

    什么！？居然还是413？？？

    嗷，原来是NGINX忘记刷新了，reload一下，顺利执行！

    美滋滋，这下可以实现数据同步自由了。后续还有待查看如何配置EO才能正常加速到目标文件而且又不影响到WEBDAV协议。