上传一直失败？修复常见文件传输错误

上传失败几乎总是落入五个类别之一：网络不稳定（Wi-Fi 断线、ISP 重新路由）、浏览器内存耗尽（Chrome 在标签页占用 2 GB 内存时将其杀死）、服务端限速或配额超限、源文件损坏，或防病毒软件/防火墙拦截了出站请求。首先打开开发者工具的"网络"标签，查看失败请求的实际 HTTP 状态码：413 是"请求体过大"，502 或 503 是服务端问题，"ERR_CONNECTION_RESET"是网络问题。每种情况有不同的修复方法。

读懂实际报错，而不是模糊提示

多数上传界面显示"上传失败"就完事了，这毫无用处。打开浏览器开发者工具（F12 或 Cmd+Option+I），切换到"网络"标签，查看失败的请求。状态码告诉你问题在哪：4xx 系列是你这边的问题（413 太大、401 未授权、403 禁止访问），5xx 系列是服务端问题（502 网关错误、503 限速、504 超时）。ERR_CONNECTION_RESET 或 net::ERR_NETWORK_CHANGED 这类连接错误意味着 TCP 连接在传输中途断开了。

关闭任何内容前先截图保存失败请求及其响应头。如果需要联系支持，这些头信息通常能直接定位问题所在。

Wi-Fi 断线：隐形杀手

笔记本的 Wi-Fi 网卡有时会在接入点之间或 2.4 GHz 与 5 GHz 频段之间漫游。每次漫游都会让 TCP 连接中断零点几秒，足以杀死单流上传。实现了分块断点续传（基于 tus.io 的服务、S3 分片上传）的上传服务能撑过这种情况，单 POST 上传则不行。

能用有线就用有线。Ethernet 不会漫游。如果没有条件，至少在上传期间待在一个房间里，并禁用"自动切换 SSID"或路由器的频段引导功能。在另一个终端窗口对 1.1.1.1 持续 ping，观察是否有延迟跳跃——那正是上传失败的时间点。

浏览器崩溃和标签页被驱逐

Chrome 会在标签页超出内存阈值时将其杀死，通常是每个标签页 2—4 GB，取决于可用内存。如果某个传输服务把 10 GB 文件整个缓冲进内存再上传（糟糕的实现），浏览器必然崩溃。如果服务使用 File API 的 slice() 方法流式分块传输（良好实现），无论文件多大，内存占用都只有几百 MB。

如果浏览器在大文件上传时持续崩溃，试试 Firefox——历史上 Firefox 在大型 File API 上传时的内存压力比 Chromium 小。确保服务使用的是分块上传；如果 5 GB 文件在 POST 前被整个加载进单个 Blob，那是设计问题。

上传前关掉所有其他标签页、重启浏览器，并禁用扩展程序（广告拦截器、隐私扩展和密码管理器有时会注入上传流程并导致问题）。

企业防火墙和代理

企业网络常常运行深度包检测、流量整形或注入证书的代理服务器。典型症状：小文件上传成功，但在特定大小（通常 100 MB 或 1 GB）时失败；或报错显示"SSL 握手失败"或"证书验证失败"。

验证方法：切换到手机热点（企业网络之外）上传。如果热点能成功，问题就在你这边的网络。解决方案：请 IT 将服务上传端点加入白名单，使用 VPN 绕过流量整形（如果允许的话），或切换到个人网络。

Zscaler、Cisco Umbrella 和 Palo Alto 设备是常见的罪魁祸首，它们经常在文件超过一定大小后进行检测，并因大文件流超时而中断连接。

防病毒软件扫描出站流量

Windows Defender、Bitdefender、Norton 和 Kaspersky 可以通过拦截 TLS 来扫描出站 HTTPS 流量。在大文件上传时，扫描本身可能降低吞吐量 40%—60%，某些版本还会引入超时，断掉连接。

临时禁用实时网页保护（不是整个防病毒程序，只是 HTTPS 检测组件），然后重试。如果上传成功，将传输服务的域名添加到防病毒软件的排除列表。不要长期关闭网页保护。

服务端限速

如果收到 429 或 503 响应，服务正在限制你的请求。可能原因：并行分块数量过多（从 8 个 worker 减到 4 个）、触及免费套餐的每日配额（WeTransfer 免费版每次传输上限 2 GB，但有隐性的每日总量限制），或所在 IP 已被标记（酒店或咖啡馆 Wi-Fi 被滥用后的常见情况）。

等待 15 分钟后重试，或切换网络，或换一个服务。

源文件本身损坏

极少数情况下，文件本身就是问题所在。文件系统损坏（外部硬盘坏道、复制中断）会产生一个文件，前几 MB 读取正常，之后出现 I/O 错误。上传在固定进度卡住，每次重试都一样。

先把文件复制到另一个本地磁盘测试。如果复制也在相同进度失败，说明是源文件有问题。在 Windows 上运行 chkdsk，在 macOS 上运行 diskutil verifyDisk 检查源驱动器。关键文件应从已知正常的备份中恢复后再尝试上传。

系统时间与 TLS 证书错误

如果系统时钟偏差超过几分钟，TLS 证书验证会失败，上传报错"证书尚未生效"之类的提示。Mac 和 Windows 通常通过 NTP 自动同步，但长时间休眠或主板电池耗尽后，时钟会漂移。

强制 NTP 同步：macOS 用 sntp -sS time.apple.com，Windows 在"设置 > 时间和语言 > 日期和时间 > 立即同步"。

VPN 静默失效

一些 VPN 客户端（尤其是免费版）因会话令牌每 5—10 分钟刷新，会断掉长时间 TCP 连接。一个需要 20 分钟的 2 GB 上传，会在令牌刷新时无声无息地中断。要么换用会话处理更好的付费 VPN（Mullvad、ProtonVPN、IVPN），要么在上传期间断开 VPN——如果服务本身已有端对端 TLS 加密，传输过程中不需要 VPN 来保障机密性。

HexaTransfer 等端对端加密服务在文件离开浏览器前已用 AES-256-GCM 客户端加密，叠加 VPN 加密是双重保险，而非必须。

选择能自动重试分块的服务

如果本地问题都排查完了上传仍然失败，可能是服务本身对中断的处理不够好。具备每分块自动重试和可恢复会话状态的服务，能撑过那种会杀死单流上传的网络抖动（Wi-Fi 漫游、短暂 ISP 重路由）。HexaTransfer 采用并行分块上传，每块独立重试，大多数短暂网络事件无需手动干预即可自动恢复。

在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。