Dufs项目中的iOS/iPadOS大文件上传问题分析与解决方案

问题背景

在使用Dufs文件服务器时，用户发现通过iOS/iPadOS设备上的Safari浏览器上传超过105MB的大文件时会失败，而同样的操作在MacBook上的Safari却能成功。这个问题主要出现在移动设备上，上传过程会在达到约105MB时中断。

问题分析

从日志中可以观察到几个关键点：

1. 上传过程中出现了"error reading a body from connection"错误
2. 服务器返回了500状态码
3. 请求最终以502 Bad Gateway结束
4. 上传中断时传输的数据量约为105MB

这些现象表明问题可能出在网络连接层面，而非Dufs服务器本身。特别是502状态码和连接读取错误，通常意味着中转服务器或网络中间件在传输过程中中断了连接。

根本原因

经过深入分析，发现问题的根源在于Traefik反向代理的默认超时设置。Traefik默认配置了读取超时(readTimeout)，当上传大文件时，如果传输时间超过了这个阈值，Traefik就会主动关闭连接，导致上传中断。

iOS/iPadOS设备由于网络性能和处理能力的限制，上传速度可能较慢，更容易触发这个超时限制。而MacBook通常有更强的处理能力和更稳定的网络连接，因此不容易遇到这个问题。

解决方案

针对这个问题，最有效的解决方案是调整Traefik的配置，特别是响应超时设置。具体修改如下：

entryPoints:
  https:
    transport:
      respondingTimeouts:
        readTimeout: 0

这个配置将读取超时设置为0，即禁用读取超时限制，允许长时间的文件上传操作。修改后，iOS/iPadOS设备也能成功上传大文件。

技术建议

1. 对于需要处理大文件上传的场景，建议总是检查并适当调整反向代理的超时设置
2. 考虑实现分块上传或断点续传功能，提高大文件上传的可靠性
3. 监控网络性能，确保服务器和客户端之间有足够的带宽支持大文件传输
4. 在生产环境中，应该根据实际需求设置合理的超时值，而不是简单地禁用超时

总结

Dufs文件服务器本身功能正常，iOS/iPadOS设备上的大文件上传问题主要是由中间件(Traefik)的默认超时设置引起的。通过调整反向代理的配置，可以解决这个问题，使所有平台都能顺利上传大文件。这个案例也提醒我们，在处理文件传输相关问题时，需要全面考虑整个技术栈中各组件的配置和交互。