上行和下行为什么不对称
家庭和多数办公宽带的上行带宽明显小于下行，这是常识，但它带来的影响常被低估。一个几百兆的文件在下行看是很快的事，在上行可能需要十几分钟到几十分钟——而时间越长，中途遇到一次波动的概率就越高。
更关键的是，上传通常是一次性的长请求：客户端把整个文件作为一个请求体持续往外送，中间不能停。任何一次中断都意味着这个请求作废。而下载可以被分割成很多个小请求，中断一个只影响一小段。
据 Amazon S3 官方文档对分段上传（multipart upload）的说明，大对象可以被拆成多个部分分别上传，各部分可独立重试，最终在服务端合并为一个对象。这正是为了解决上面这个问题——把一个长请求换成许多短请求，让单次失败的代价从「整个文件」降到「一个分片」。
总在同一个百分比失败，说明什么
失败位置有规律是一个很有价值的线索。
总在相同百分比失败：通常指向一个固定的限制，比如某个环节的请求体积上限、或者一个固定的超时时长。上传到那个点刚好触碰到限制，于是每次都在同一位置断。这一类换网络往往没用，因为限制在服务端或者中间某个固定环节。
失败位置随机：更像链路波动。这一类换网络、换时间段可能有明显变化。
刚开始就失败：那不是传输问题，多半是这次上传在协商阶段就被拒了——文件类型、大小上限、或者会话已过期。看报错文本比看进度更有用。
会话过期这个隐形杀手
上传大文件耗时长，而很多平台的登录会话有有效期。如果上传耗时超过了会话有效期，最后提交的那一刻会因为身份失效而失败——而进度条已经走到了 100%，用户看到的是「传完了却失败了」，非常容易误判为文件有问题。
特征是：越大的文件越容易失败，而且总是在接近完成时失败。遇到这种形态，先在另一个标签页里刷新一下平台页面，确认登录状态是否还在。
这也是分批上传的另一个理由：每一批都短，都在会话有效期内完成，就绕开了这个陷阱。
排查顺序
第一步，读报错文本，不要只看进度。「文件过大」「类型不支持」「会话已过期」「网络错误」指向完全不同的原因。
第二步，用一个小文件试。小文件成功说明通道和权限都没问题，问题在体积或耗时相关的机制上；小文件也失败说明是可达性或权限问题，方向完全不同。
第三步，看失败位置是否固定。固定位置指向固定限制，随机位置指向链路波动。
第四步，检查上传期间的登录状态。另开一个标签页刷新平台页面，确认会话还在。
第五步，分批或压缩。把一个大文件拆成几个、或者先压缩再传，把每次上传的耗时压到足够短。这是最有效也最容易被跳过的一步。
能改和不能改的
能改的：把大文件拆小；先压缩；避开自己网络的高峰时段；如果平台提供专门的上传工具或者支持分段上传的接口，用它而不是网页表单；减少经过的中间环节，让连接更稳。
不能改的：你无法提高自己宽带的上行带宽上限，也无法改变平台侧的请求体积上限和会话有效期。这两头都不在你手里，所以可行的方向集中在「让每次上传更短、更稳」这一件事上。
如果换网络这一步显示不同路径差异明显，那说明中间环节确实在影响稳定性，减少环节比反复重试更有意义。
上行耗时越短越不容易断，少绕几道是最直接的一手。安卓与 Windows 客户端已上线，macOS 与 Linux 开发中。iPhone 暂无原生客户端。注册即可使用永久免费套餐，按月发放流量额度。
据 Amazon S3 官方文档对分段上传（multipart upload）的说明，大对象可以拆成多个部分分别上传、各部分独立重试。
常见问题
下载都正常，为什么上传总失败？
上行和下行条件不对称。上行带宽通常小得多，同样大小的文件上传耗时长很多，中途遇到波动的概率更高；而且上传常常是一次性的长请求，中断一次整个请求就作废，下载可以分成小段，中断一段只影响一小部分。
总在同一个百分比失败是什么原因？
通常指向一个固定的限制，比如某个环节的请求体积上限或者固定的超时时长。这一类换网络往往没用，因为限制在服务端或者中间某个固定环节，需要改的是上传方式而不是线路。
进度走到 100% 了还是失败，文件有问题吗？
多半不是文件问题。上传耗时超过登录会话有效期时，最后提交那一刻会因为身份失效而失败。特征是越大的文件越容易失败、而且总在接近完成时失败。另开标签页刷新平台页面确认登录状态。
刚开始上传就失败呢？
那不是传输问题，多半在协商阶段就被拒了——文件类型不支持、超过大小上限、或者会话已经过期。这时候看报错文本比看进度有用得多。
分段上传是什么，对我有用吗？
就是把一个大文件拆成多个部分分别上传、各部分可独立重试、最后在服务端合并。它把单次失败的代价从整个文件降到一个分片。如果平台提供支持分段上传的工具或接口，用它比用网页表单稳得多。
先压缩再传有用吗？
有用，因为它直接减少了需要传输的字节数，从而缩短耗时。耗时越短，撞上中断和会话过期的概率越低。对产品图这类可压缩内容效果通常明显。
怎么快速判断是不是我的网络问题？
先用一个很小的文件试。小文件成功说明通道和权限都没问题，问题在体积或耗时相关的机制上；小文件也失败说明是可达性或权限问题，两个方向完全不同。
能不能提高自己的上行速度？
宽带的上行带宽上限不在你手里，平台侧的体积上限和会话有效期也不在。可行的方向集中在让每次上传更短更稳：拆分、压缩、避开高峰、减少中间环节。