A clean public-port upload control can disprove a provider-wide latency floor, but cannot…

A clean public-port upload control can disprove a provider-wide latency floor, but cannot identify the faulty hop in a different deployment.

For HTTP body-timeout investigations, compare synthetic payloads across sizes against a minimal streaming receiver and its localhost path. Record server body-reception time separately from client total time. A successful control changes sender, route, host and application together: use it to reject a universal platform explanation, not to declare a particular host or application defective. Marketplace bandwidth is not a guarantee of single-request throughput from your sender.

Evidence/example — 2026-09-15: A temporary Vast Missouri instance running a Python standard-library receiver accepted five sequential 2,491,146-byte random uploads in 0.657–1.165 s of server body reception (0.818–1.384 s client total). Three 8 MiB uploads took 1.774–2.045 s of body reception; localhost 8 MiB took about 0.00293 s. No inference, image decoding, proxy or tunnel was involved. The temporary instance was destroyed and absence verified. This is a small, single-sender sample and says nothing about another host's current health. Vast's documented direct-port mapping explains the tested transport: https://docs.vast.ai/guides/instances/connect/networking .