Unlike a cloud scrubbing center, which pulls traffic away to a remote facility and tunnels the remainder back, a clean pipe does not move your traffic off its normal route; it filters it inside the provider's network before it reaches the circuit you pay for. Whether that filtering holds at the volume and on the paths an attacker actually uses is what a DDoS test checks. The term describes a delivery model, usually sold by an ISP or transit carrier: the customer receives a "clean" pipe with volumetric floods and known attack patterns removed upstream, rather than running scrubbing capacity of its own.
Why upstream is the only place that works
The reason the model exists is the access circuit. A site on a 10 Gbps link cannot defend that link from its own side of it: once a volumetric attack exceeds 10 Gbps, the circuit is full, and any firewall or appliance behind it is filtering a stream that has already lost the legitimate traffic. The filtering has to happen where capacity is larger than the attack, which means inside the carrier.
Because filtering happens on the carrier's side of the same circuit, nothing is tunnelled. Cloud scrubbing typically returns clean traffic over GRE, which adds 24 bytes to every packet and usually needs MSS clamping to stop large packets fragmenting or vanishing. A clean pipe delivers on the link you already have, so that class of problem does not arise.
The cost is dependency. The protection is a property of one provider's network, and it only covers traffic that enters through that provider.
Where it leaks
Multi-homing is the classic gap. A site with two upstream carriers, only one of which provides a clean pipe, is protected on half its inbound paths. Internet routing, not the attacker, decides which carrier a given flood arrives through, and whatever comes in on the unprotected transit fills that circuit untouched.
Enrolment is the quieter gap. A clean-pipe contract covers named prefixes. A new address block announced later, or a service moved to a range nobody added to the agreement, is carried across the same circuit but not scrubbed.
Clean traffic still has to fit. The pipe removes attack traffic, not demand, so a flash crowd or a flood of valid-looking application requests that passes the filters still lands on the circuit at full size. And most carrier offerings are on-demand rather than always-on: detection on the carrier's flow telemetry triggers mitigation, so there is a cutover window while the circuit takes the hit.
What a DDoS test measures
A test treats the contract as a hypothesis. It measures what actually arrives at the customer edge during an attack, the residual leakage after the carrier's filters, rather than trusting the provider's dashboard, and it times how long the circuit runs saturated before mitigation engages.
It then tests the paths. Traffic is sent toward every protected prefix, and where the site is multi-homed, from sources that will route in over each upstream, to confirm that every way in is scrubbed. Prefixes outside the contract show up immediately.
One practical note: testing through a carrier's network means the carrier has to know. An unannounced test against a clean-pipe customer looks like an attack on the carrier too, and gets mitigated, or escalated, accordingly.
Where the carrier sits relative to your own perimeter is one of several places where an on-premise network's defence is decided before traffic reaches it, and on-premise DDoS testing sets out the rest.