带宽优化技巧：让文件传输更快
最大化文件传输的可用带宽。学习能显著提高上传速度的路由器设置和网络调整。
要充分利用上传带宽，做好四件事：改用千兆 Ethernet 有线接入而非 Wi-Fi，在路由器上开启 QoS 或 SQM 以消除缓冲区膨胀，在 ISP 支持的情况下切换到 IPv6，以及传输期间暂停 Dropbox、iCloud 和 Google Drive 等后台同步。在实际传输只有 180 Mbps 的 500 Mbps 上传线路上，这四项措施加在一起通常能恢复 200—280 Mbps 的可用吞吐量，让 10 GB 的传输时间从 45 分钟缩短到 15 分钟以内。
接有线网络，大文件别用 Wi-Fi
Wi-Fi 6（802.11ax）在距离接入点 1.5 米、无障碍的 2x2 客户端上，实际吞吐量上限约 600 Mbps。Wi-Fi 5（802.11ac）接近 300 Mbps。隔一堵墙，这两个数字会下降 40%—60%。千兆 Ethernet 能稳定提供 940 Mbps，抖动低于 1 ms。
一个价格约 15 美元的 USB-C 转千兆 Ethernet 适配器，在处理超过 2 GB 的文件上传时，会比大多数笔记本内置 Wi-Fi 更快。如果实在无法拉网线，至少切换到 5 GHz 频段并保持与路由器的视距范围。2.4 GHz 在实际条件下上限约 60—80 Mbps，不适合承载文件传输。
QoS 与 SQM：消除缓冲区膨胀
缓冲区膨胀（bufferbloat）是为什么家里有人开始上传大文件时 Zoom 通话就开始卡顿的根本原因。传统路由器缓冲区在链路饱和时会将数据包排队数秒，破坏延迟。智能队列管理（SQM）算法（如 CAKE 和 fq_codel）即使在高负载下也能保持队列短小，使 500 Mbps 的上传不会给其他流量增加 300 ms 的延迟。
OpenWrt、pfSense 以及大多数现代路由器（搭载 Merlin 固件的 Asus、Ubiquiti UniFi、eero Pro 6E）都支持 SQM。启用后，将上行速度设置为实际签约速度的约 95%，然后用 DSLReports 或 Waveform 的缓冲区膨胀测试验证效果——评级从 F 跳到 A+ 并不罕见。
SQM 不增加带宽，但能消除 40%—60% 的吞吐量损失——这部分损失原本由缓冲区膨胀导致 TCP 发送方反复退让引起。
IPv6 通常更快
在支持双栈的 ISP 上，IPv6 到主流云端目标的路由往往更直接。AWS、Google Cloud、Cloudflare 和 Azure 全部原生支持 IPv6，IPv6 数据包通常能绕过移动端和部分家用网络常见的 IPv4 CGNAT 路径（多 1—2 跳 NAT）。
通过 ipv6-test.com 或 test-ipv6.com 检测。如果得分 10/10，你在可用时已经在走 IPv6。如果没有，在路由器中启用（大多数 ISP 通过 DHCPv6 或 PPPoE 自动推送配置）。对于跨洲际上传，差异可达 20%—40%。
关闭所有后台同步
Dropbox、Google Drive、OneDrive、iCloud Photos、网络 Time Machine，以及 Backblaze 等备份工具，都在悄悄消耗上传带宽。macOS 的 Activity Monitor（网络选项卡，按"已发送字节数"排序）和 Windows 的资源监视器能揭露元凶。
大文件传输前暂停它们。iCloud Photos 在导入一批照片后会悄悄推送几个 GB。Backblaze 的默认限速是"自动"，即在空闲连接上"尽情使用"。
Zoom 1080p 通话消耗约 3 Mbps 上行；Google Meet 高清通话约 2.5 Mbps。如果家里有人在视频会议，要么围绕会议安排传输时间，要么接受 2—3 Mbps 的损耗。
DNS 与首字节时间
配置错误的 DNS 可能在 TCP 连接建立之前就增加 50—200 ms 的延迟。如果还在使用 ISP 默认的 DNS 解析器，可以尝试 Cloudflare 的 1.1.1.1 或 Google 的 8.8.8.8。用 dig +stats transfer-service.com 对比响应时间。对于开启多连接的分块上传，快速的解析器会带来可察觉的整体吞吐量提升。
在 macOS 上修改：系统设置 → 网络 → 详细信息 → DNS。在 Windows 11 上：设置 → 网络和 Internet → 你的网络适配器 → 编辑 DNS 服务器分配。
特殊网络环境下的 MTU 调优
如果你在使用 VPN、PPPoE DSL 连接或移动网络上行，MTU 可能低于默认的 1500 字节。MTU 配置不当会导致 TCP 分片、重传和吞吐量崩溃。在 macOS/Linux 上用 ping -s 1472 -D google.com，Windows 上用 ping -f -l 1472 google.com 测试。若数据包无法返回，以 10 字节为单位逐步降低 MTU，直到正常返回，然后将该值（加上 28 字节的 ICMP 开销）设为接口 MTU。
常见可用值：大多数宽带 1500，PPPoE DSL 1492，部分 WireGuard VPN 1428，大多数 5G 运营商 1400。
拥塞控制算法：BBR 对比 Cubic
在 Linux 系统上上传到云端时，将 TCP 拥塞控制算法从 Cubic 切换到 BBR（瓶颈带宽和往返时间算法），在高延迟、轻微丢包的链路上吞吐量可能翻倍。启用命令：sysctl -w net.ipv4.tcp_congestion_control=bbr。macOS 和 Windows 默认使用 Cubic 变体，不容易暴露此设置，但越来越多的云传输端点已在服务端运行 BBR，即使你的客户端不支持也能受益。
这也是托管在 Google Cloud 上的服务（如 Smash，以及部分 SwissTransfer 流量）有时感觉比运行在传统主机上的相同服务更快的原因之一。
浏览器选择有影响
基于 Chromium 的浏览器（Chrome、Edge、Brave、Arc）默认支持 HTTP/3 和 QUIC，在丢包链路上比 HTTPS/HTTP/2 快 15%—25%。Firefox 也支持 QUIC。Safari 17+ 支持 HTTP/3，但对部分服务默认走 HTTP/2。通过开发者工具的网络面板"协议"列可以确认。
如果传输服务的上传端点支持 HTTP/3，让浏览器自动选择意味着更少的握手往返——这对开启 4—8 路并行流的分块上传影响尤为明显。
选择不限制你带宽的服务
部分传输服务无论你的带宽有多大，都会对上传速度设置上限。50 Mbps 的线路完全可能因为服务端限速而只跑到 30 Mbps。HexaTransfer 通过 HTTP/2 并行分块流传输数据，在 Web Worker 中完成 AES-256-GCM 加密，上传速度上限由你的实际连接决定，而不是由服务端的人工节流决定。
在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。