Internetsnelheid testen met CMD: waarom de meting kan afwijken

Internetsnelheid testen met CMD helpt vooral om latency, packet loss en routeringsproblemen te herkennen. Toch meet CMD niet automatisch je volledige download- en uploadsnelheid. Afwijkende resultaten komen vaak door Wi-Fi, modem/routerbelasting, DNS, ISP-routing, achtergrondverkeer of een verkeerde testmethode.

Gepubliceerd 2026-07-30 Laatst bijgewerkt 2026-07-30 Categorie: Gidsen

Wie internetsnelheid wil testen met CMD gebruikt meestal opdrachten zoals ping, tracert, pathping of soms curl. Dat kan nuttige signalen geven over latency, jitter, pakketverlies en de route naar een server. Het is alleen belangrijk om te weten dat CMD standaard geen volledige speedtest uitvoert zoals een browsergebaseerde test dat doet.

Een lage downloadsnelheid, haperende videogesprekken, trage uploads naar cloudopslag of hoge ping in games kunnen allemaal anders zichtbaar worden in CMD. Daarom is de juiste vraag niet alleen hoe je meet, maar ook waarom de uitkomst afwijkt van wat je verwacht.

Wat meet je precies met CMD?

Met ping meet je vooral hoe lang een klein datapakket erover doet om naar een server te gaan en terug te komen. Dat zegt iets over latency, maar niet direct over je maximale downloadsnelheid of uploadsnelheid.

Met tracert zie je via welke tussenstappen je verbinding naar een bestemming loopt. Dit helpt bij het herkennen van vertraging buiten je eigen netwerk, bijvoorbeeld bij een drukke route tussen je provider en een buitenlandse server.

Met pathping kun je over meerdere stappen packet loss en vertraging bekijken. Dat is nuttig als de verbinding niet alleen traag voelt, maar ook onstabiel is.

Met tools zoals curl kun je een bestand downloaden vanaf de opdrachtregel, maar de uitkomst hangt sterk af van de gekozen server, bestandsgrootte, protocol, schijfsnelheid en tijdelijke netwerkdrukte.

Probleemverschijnselen bij CMD-metingen

Een veelvoorkomend verschijnsel is dat ping normaal lijkt, terwijl downloads traag blijven. Dit betekent meestal dat de basisvertraging laag is, maar dat de beschikbare bandbreedte, Wi-Fi-kwaliteit of servercapaciteit toch beperkt is.

Een ander verschijnsel is wisselende ping. Als de ene meting 12 ms toont en de volgende 150 ms, wijst dat vaak op jitter, drukte op Wi-Fi, bufferbloat of tijdelijke belasting op de router/modem.

Bij request timed out of zichtbaar packet loss kan er sprake zijn van draadloze storing, slechte bekabeling, overbelaste netwerkapparatuur of problemen verderop bij de ISP/operator.

Ook kan CMD een lagere snelheid suggereren dan een commerciële speedtest. Dat gebeurt vaak wanneer je test naar een kleine of verre server, terwijl een speedtestplatform juist automatisch een dichtbijgelegen en snelle server kiest.

Oorzaak 1: CMD meet latency, niet automatisch downloadsnelheid

De belangrijkste oorzaak van verwarring is dat ping geen snelheidstest is. Ping gebruikt kleine pakketjes en meet reactietijd. Een glasvezelverbinding van 1 Gbit/s en een DSL-lijn van 50 Mbit/s kunnen naar dezelfde server vergelijkbare pingwaarden tonen, terwijl hun downloadsnelheid sterk verschilt.

Daarom kun je met CMD goed zien of de verbinding reageert en of er pakketverlies optreedt, maar niet zonder extra download- of uploadtest bepalen of je abonnementssnelheid wordt gehaald.

Oorzaak 2: Wi-Fi vertekent de meting

Wi-Fi is vaak de grootste bron van wisselende resultaten. Afstand tot de router, dikke muren, buren op hetzelfde kanaal, oudere laptops, mesh-overgangen en gebruik van 2,4 GHz in plaats van 5 GHz of 6 GHz kunnen de meting sterk beïnvloeden.

Als CMD via Wi-Fi hoge latency, wisselende tijden of packet loss laat zien, betekent dat niet automatisch dat je provider traag is. Het kan simpelweg betekenen dat de draadloze verbinding tussen apparaat en router/modem instabiel is.

Oorzaak 3: Router of modem is overbelast

Een router/modem kan traag reageren wanneer er veel apparaten actief zijn, firmware verouderd is, QoS verkeerd staat ingesteld of de hardware moeite heeft met veel gelijktijdige verbindingen. Dit zie je vaak als de ping naar de router zelf al onrustig is.

Test daarom eerst naar het lokale gateway-adres, bijvoorbeeld je router. Als die meting al hoge uitschieters of packet loss toont, zit het probleem waarschijnlijk in je eigen thuisnetwerk en niet direct bij de externe verbinding.

Oorzaak 4: Achtergrondverkeer gebruikt bandbreedte

Cloudback-ups, game-updates, streaming, beveiligingscamera’s, Windows-updates en uploads vanaf andere apparaten kunnen je download, upload en latency beïnvloeden. Vooral uploadbelasting kan merkbaar zijn: als de upload volloopt, worden ook gewone websites en videogesprekken trager.

CMD kan dit zichtbaar maken door hogere ping tijdens druk netwerkgebruik. Dit wordt vaak ervaren als lag, terwijl de maximale downloadsnelheid op rustige momenten nog steeds goed kan zijn.

Oorzaak 5: DNS en serverkeuze geven een verkeerd beeld

Een trage website is niet altijd een trage internetverbinding. DNS-resolutie, de gekozen testserver, de afstand tot de server en de belasting aan de andere kant kunnen allemaal invloed hebben op de uitkomst.

Als je alleen naar één domein pingt, test je vooral de route naar die specifieke bestemming. Test daarom meerdere betrouwbare bestemmingen en vergelijk lokale, nationale en internationale routes voordat je conclusies trekt.

Oorzaak 6: ISP-routing of piekuren spelen mee

Bij providers zoals KPN, Ziggo, Odido of andere operators kan de route naar bepaalde diensten per moment verschillen. Tijdens avonduren kan er meer drukte zijn op delen van het netwerk of bij peeringpunten, waardoor latency of packet loss tijdelijk stijgt.

Als lokale tests naar je router goed zijn, maar externe routes via tracert of pathping afwijkingen tonen, kan het probleem buiten je woning liggen. Dat betekent niet altijd een storing, maar wel dat de route of bestemming de ervaring beïnvloedt.

Zo beoordeel je CMD-resultaten stap voor stap

  1. Test eerst lokaal: ping je router/modem om te controleren of je eigen netwerk stabiel is.
  2. Test daarna extern: ping een bekende, stabiele server en let op gemiddelde latency, uitschieters en packet loss.
  3. Gebruik tracert: bekijk waar vertraging ontstaat en of die binnen of buiten je netwerk begint.
  4. Vergelijk bekabeld en Wi-Fi: gebruik bij voorkeur een ethernetkabel om Wi-Fi als oorzaak uit te sluiten.
  5. Meet op meerdere momenten: vergelijk ochtend, avond en weekend om piekuren te herkennen.

Optimalisaties die meestal helpen

  • Gebruik ethernet voor controlemetingen: zo meet je dichter bij de werkelijke lijnkwaliteit van glasvezel, kabel of DSL.
  • Herstart router en modem gericht: doe dit vooral na firmware-updates, langdurige uptime of merkbare instabiliteit.
  • Verplaats Wi-Fi-apparatuur: zet de router vrij, hoog en niet direct naast metalen objecten of andere storingsbronnen.
  • Beperk achtergrondverkeer: pauzeer cloudsync, downloads en updates tijdens het testen.
  • Controleer bekabeling: gebruik geschikte ethernetkabels en vermijd beschadigde of oude kabels bij gigabitverbindingen.
  • Vergelijk met een browser-speedtest: gebruik CMD voor diagnose en een betrouwbare speedtest voor download- en uploadcapaciteit.

Wanneer moet je je provider benaderen?

Neem contact op met je ISP/operator wanneer bekabelde tests op meerdere apparaten slecht blijven, je lokale netwerk stabiel is, er structureel packet loss optreedt buiten je router, of de snelheid langdurig duidelijk onder verwachting blijft.

Noteer vooraf je testmomenten, gebruikte verbindingstype, CMD-resultaten, bekabelde speedtestresultaten en eventuele tracert- of pathping-uitkomsten. Daarmee kan de helpdesk gerichter beoordelen of het om je modem/router, de aansluiting, de wijkcentrale, coaxsegmenten, glasvezelroute of externe peering gaat.

Conclusie

Internetsnelheid testen met CMD is vooral geschikt voor oorzaakonderzoek. Het helpt bij het herkennen van latency, jitter, packet loss, lokale netwerkproblemen en routeringsverschillen. Voor de maximale download- en uploadsnelheid blijft een echte speedtest nodig, bij voorkeur bekabeld en op meerdere momenten uitgevoerd.