Skip to main content

Downloads 50x langzamer dan speedtest — throttelt Odido HTTP-verkeer?

  • March 15, 2026
  • 17 reacties
  • 185 Bekeken

Hallo,

Ik zit al jaren bij Odido op een 1 Gbps glasvezelaansluiting en merk de laatste tijd dat downloads aanzienlijk langzamer zijn dan ik zou verwachten. Na uitgebreid testen heb ik een opvallend patroon ontdekt dat ik hier wil delen.

Mijn situatie
Abonnement: Odido Glasvezel 1 Gbps
Aansluiting: bedraad via ethernet, Windows 11 PC direct op router

Het probleem: speedtest zegt iets heel anders dan de praktijk

De Ookla- én Google-speedtest geven consistent ~940 Mbps — het abonnement wordt op papier gehaald. Maar zodra ik een gewone HTTP/HTTPS-download doe naar een willekeurige server, is de snelheid een fractie daarvan. De speedtest en de dagelijkse praktijk spreken elkaar volledig tegen.

Om dit objectief te testen heb ik een eigen testbestand van 100MB geplaatst op een Nederlandse webserver. Ik heb de download herhaaldelijk gemeten via PowerShell:
 

curl -o NUL [testbestand URL]


Elke test twee keer uitgevoerd: eerst zonder VPN, daarna direct met Surfshark VPN op een Nederlandse server. De enige variabele is of Odido het verkeer kan identificeren.

Ter controle: de hostingserver zelf haalt 162 MB/s naar externe servers — de server is geen bottleneck. Mijn thuisnetwerk (switches, mesh-units) heb ik ook uitgesloten door direct bedraad op de router te testen.

**Resultaten over meerdere dagen en tijdstippen:**

| Tijdstip | Zonder VPN | Met VPN (Surfshark NL) | Verschil |
| Nacht (12/3) | ~1.2 MB/s | ~90 MB/s | 75x |
| Ochtend (13/3) | ~1.1 MB/s | ~74 MB/s | 66x |
| Middag (13/3) | ~1.8 MB/s | ~87 MB/s | 49x |
| Avond (13/3) | ~1.8 MB/s | ~91 MB/s | 51x |
| Nacht (15/3) | ~0.9 MB/s | ~85 MB/s | 90x |

De throttling zit er op elk tijdstip in — het is geen piekurenprobleem.

Waarom is de VPN zoveel sneller — en waarom is dat verdacht?

Een VPN versleutelt al het verkeer en stuurt het via een externe server. Odido ziet dan geen gewoon HTTP/HTTPS-verkeer meer, maar alleen een versleutelde tunnel naar een VPN-server. Odido kan dus niet meer zien wat voor verkeer het is.

Zodra dat het geval is, is de snelheid 50-90x hoger op exact dezelfde verbinding, hetzelfde moment, dezelfde kabel. Dat kan maar één ding betekenen: Odido behandelt HTTP/HTTPS-downloadverkeer anders dan ander verkeer. Speedtest-verkeer wordt klaarblijkelijk niet gethrotteld — gewone downloads wel.

Dit patroon is consistent over vijf meetmomenten verspreid over meerdere dagen en tijdstippen. Een storing of netwerkcapaciteitsprobleem fluctueert — dit niet. Traffic shaping wel.

Contact met klantenservice
Ik heb dit gemeld bij zowel eerste als tweede lijn. Beide gaven aan hier geen weet van te hebben. De standaardreactie: 'als de speedtest goed is, doen wij ons werk goed.' Maar een speedtest meet alleen het verkeer dat Odido zelf voortrekt — dat is geen objectieve meting van de werkelijke downloadsnelheid. Na aandringen werd mij geadviseerd een formele klacht in te dienen.

Mijn vragen:
1. Kunnen anderen dit reproduceren? Doe de test zelf via PowerShell:

curl -o NUL https://fsn1-speed.hetzner.com/100MB.bin

   Eerst zonder VPN, daarna met VPN op een NL-server. Wat zijn jullie resultaten?
   De URL van mijn eigen testbestand op een Nederlandse server deel ik graag via PM voor wie dat wil vergelijken.
2. Mag Odido op deze manier ingrijpen in het downloadverkeer? Speedtest-verkeer voorrang geven boven gewone HTTP/HTTPS-downloads lijkt mij in strijd met de EU Netneutraliteitsverordening (2015/2120).

Benieuwd naar ervaringen en inzichten van anderen.

March 16, 2026

Hoi ​@jjonker, welkom op onze community!

Dank voor het uitgebreide onderzoek en het delen van de resultaten. Het verschil dat je ziet tussen een speedtest en een daadwerkelijke download komt vaker voor en heeft meestal andere oorzaken dan traffic shaping of throttling. Waarom een speedtest bijna altijd sneller lijkt: Een speedtest (bijvoorbeeld via Speedtest by Ookla) is speciaal ontworpen om de maximale capaciteit van je verbinding te meten. Dat gebeurt onder ideale omstandigheden:

  • De testserver staat vaak dichtbij in het netwerk.

  • Er worden meerdere verbindingen gebruikt.

  • De testservers hebben extreem hoge capaciteit.

  • Routes tussen provider en testserver zijn meestal direct gepeerd.

Daardoor meet een speedtest vooral de capaciteit van jouw lijn, niet per se de snelheid naar elke willekeurige server op internet. Waarom een gewone download vaak langzamer is: Een normale download via HTTP/HTTPS hangt af van veel meer factoren:

  1. Capaciteit van de downloadserver, niet elke server kan honderden megabits per gebruiker leveren.
  2. Aantal verbindingen, browsers of tools gebruiken vaak 1 of een paar TCP-verbindingen. Speedtests gebruiken er vaak 8–16 tegelijk.
  3. TCP-congestion control, bij 1 verbinding duurt het langer voordat TCP volledig opschaalt.
  4. Routing en peering, de route naar een specifieke host kan via andere netwerken lopen dan een speedtest.
  5. CDN en caching, speedtests draaien vaak op CDN-infrastructuur, terwijl een willekeurige server dat niet doet.

Waarom een VPN soms sneller kan lijken, het klopt dat een VPN, zoals Surfshark, het verkeer eerst naar een andere server stuurt. Daardoor kan het volgende gebeuren:

  • De routing verandert.

  • Het verkeer komt via een andere transitprovider binnen.

  • TCP-optimalisaties van de VPN-server kunnen effect hebben.

Dat kan in sommige gevallen paradoxaal genoeg een hogere downloadsnelheid opleveren, vooral als de originele route minder efficiënt is. Dat betekent echter niet automatisch dat verkeer zonder VPN wordt beperkt. Een speedtest meet de maximale capaciteit van je verbinding onder ideale omstandigheden, terwijl een normale download afhankelijk is van de server, routing en het aantal verbindingen. Daardoor kunnen de resultaten flink verschillen.

 

17 reacties

Tommie van Odido
Moderator
Forum|alt.badge.img+13
  • Moderator | Internet + TV
  • March 16, 2026

Hoi ​@jjonker, welkom op onze community!

Dank voor het uitgebreide onderzoek en het delen van de resultaten. Het verschil dat je ziet tussen een speedtest en een daadwerkelijke download komt vaker voor en heeft meestal andere oorzaken dan traffic shaping of throttling. Waarom een speedtest bijna altijd sneller lijkt: Een speedtest (bijvoorbeeld via Speedtest by Ookla) is speciaal ontworpen om de maximale capaciteit van je verbinding te meten. Dat gebeurt onder ideale omstandigheden:

  • De testserver staat vaak dichtbij in het netwerk.

  • Er worden meerdere verbindingen gebruikt.

  • De testservers hebben extreem hoge capaciteit.

  • Routes tussen provider en testserver zijn meestal direct gepeerd.

Daardoor meet een speedtest vooral de capaciteit van jouw lijn, niet per se de snelheid naar elke willekeurige server op internet. Waarom een gewone download vaak langzamer is: Een normale download via HTTP/HTTPS hangt af van veel meer factoren:

  1. Capaciteit van de downloadserver, niet elke server kan honderden megabits per gebruiker leveren.
  2. Aantal verbindingen, browsers of tools gebruiken vaak 1 of een paar TCP-verbindingen. Speedtests gebruiken er vaak 8–16 tegelijk.
  3. TCP-congestion control, bij 1 verbinding duurt het langer voordat TCP volledig opschaalt.
  4. Routing en peering, de route naar een specifieke host kan via andere netwerken lopen dan een speedtest.
  5. CDN en caching, speedtests draaien vaak op CDN-infrastructuur, terwijl een willekeurige server dat niet doet.

Waarom een VPN soms sneller kan lijken, het klopt dat een VPN, zoals Surfshark, het verkeer eerst naar een andere server stuurt. Daardoor kan het volgende gebeuren:

  • De routing verandert.

  • Het verkeer komt via een andere transitprovider binnen.

  • TCP-optimalisaties van de VPN-server kunnen effect hebben.

Dat kan in sommige gevallen paradoxaal genoeg een hogere downloadsnelheid opleveren, vooral als de originele route minder efficiënt is. Dat betekent echter niet automatisch dat verkeer zonder VPN wordt beperkt. Een speedtest meet de maximale capaciteit van je verbinding onder ideale omstandigheden, terwijl een normale download afhankelijk is van de server, routing en het aantal verbindingen. Daardoor kunnen de resultaten flink verschillen.

 


  • Auteur
  • is een Top Poster
  • March 16, 2026

Hoi, dank voor je reactie.

Ik begrijp de uitleg over speedtests versus gewone downloads, maar deze verklaring dekt mijn bevindingen niet. Ik ga graag op een aantal punten in:

1. Serverkapaciteit
De server die ik gebruik (Oxilion) haalt zelf ~162 MB/s naar externe servers. Serverkapaciteit is dus geen beperkende factor.

2. TCP slow start / aantal verbindingen
Mijn downloads duren 1 tot 2 minuten voor 100 MB. TCP slow start speelt enkele seconden — niet minuten. Bij ~1 MB/s over een volledige download is er iets anders aan de hand.

3. Routing en peering
Traceroute naar de testserver toonde een schone route met lage latency. Er is geen aanwijzing voor een routeringsprobleem.

4. VPN verandert routing
Dit is de kern van mijn vraag. Als het verschil puur door routing of peering komt, waarom is het dan consistent 50-90x sneller met VPN — op elk tijdstip, over meerdere dagen, naar meerdere servers? Een routeringsprobleem fluctueert. Dit niet.

De enige variabele tussen de twee metingen is of Odido het verkeer kan identificeren als HTTP/HTTPS-downloadverkeer. Met VPN ziet Odido alleen versleuteld verkeer en verdwijnt het probleem direct.

Mijn concrete vragen, waar ik nog geen antwoord op heb gekregen:

1. Past Odido verkeersmanagement of traffic shaping toe op HTTP/HTTPS-downloadverkeer?
2. Zo ja, is dit beleid transparant gecommuniceerd aan klanten?
3. Kan Odido verklaren waarom het verschil zonder/met VPN consistent 50-90x is over meerdere dagen en tijdstippen?


  • is een Top Poster
  • March 16, 2026

1. Past Odido verkeersmanagement of traffic shaping toe op HTTP/HTTPS-downloadverkeer?

Nee, dit gebeurt niet. Simpelweg omdat het niet is toegestaan. Daarnaast heeft een provider er ook niets aan om al het HTTP/HTTPS-verkeer af te knijpen. Dat zou betekenen dat vrijwel alle downloads voor klanten traag worden, terwijl alleen speedtests goede resultaten laten zien. In de praktijk zou dat direct opvallen en tot klachten leiden. Het is dan ook geen discussie die je als provider gaat winnen.

Ik heb het ook even getest voor de zekerheid en zie geen gekke dingen. 

Uit onderstaande test zonder VPN blijkt dat downloadsnelheden via HTTP gewoon goed zijn en niet kunstmatig worden afgeknepen:

sven@pc01:~$ curl -o NUL https://fsn1-speed.hetzner.com/100MB.bin
100 100M 100 100M 0 0 53.7M 0 0:00:01 0:00:01 --:--:-- 53.7M

sven@pc01:~$ curl -o NUL https://fsn1-speed.hetzner.com/10GB.bin
100 10.0G 100 10.0G 0 0 74.7M 0 0:02:16 0:02:16 --:--:-- 54.9M

Ook de route naar fsn1-speed zit er prima uit. Verkeer gaat over AMS-IX naar Hetzner.

 mtr -z -c 1 -r fsn1-speed.hetzner.com
Start: 2026-03-16T12:59:33+0100
HOST: cpe-srv Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway 0.0% 1 0.4 0.4 0.4 0.4 0.0
2. AS50266 xxx-xxx-146-85.ftth 0.0% 1 2.6 2.6 2.6 2.6 0.0
3. AS??? 10.250.115.33 0.0% 1 2.7 2.7 2.7 2.7 0.0
4. AS??? 10.10.80.185 0.0% 1 3.4 3.4 3.4 3.4 0.0
5. AS??? 10.10.80.210 0.0% 1 4.9 4.9 4.9 4.9 0.0
6. AS??? 10.226.4.12 0.0% 1 5.0 5.0 5.0 5.0 0.0
7. AS24940 core51.ams.hetzner. 0.0% 1 5.6 5.6 5.6 5.6 0.0
8. AS??? amsix-gw.hetzner.co 0.0% 1 5.2 5.2 5.2 5.2 0.0
9. AS24940 core51.ams.hetzner. 0.0% 1 5.3 5.3 5.3 5.3 0.0
10. AS24940 core5.fra.hetzner.c 0.0% 1 27.2 27.2 27.2 27.2 0.0
11. AS24940 core23.fsn1.hetzner 0.0% 1 15.4 15.4 15.4 15.4 0.0
12. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
13. AS24940 fsn1-speed.hetzner. 0.0% 1 15.5 15.5 15.5 15.5 0.0

 Hoe ziet de route er voor jou uit naar fsn1-speed.hetzner.com


  • Auteur
  • is een Top Poster
  • March 16, 2026

Hoi svenvg93, dank voor het testen — interessant dat jij wel goede snelheden haalt. Dat suggereert inderdaad dat het geen netwerkbreed beleid is maar mogelijk specifiek mijn aansluiting betreft.

Mijn traceroute naar fsn1-speed.hetzner.com zag er eerder zo uit:


Tracing route to nbg1-speed.hetzner.com [88.198.248.254]
  1    <1 ms   192.168.2.1
  2     3 ms   1-184-174-82.ftth.glasoperator.nl [82.174.184.1]
  3     6 ms   10.227.147.129
  4     6 ms   10.227.147.124
  5     6 ms   10.226.9.20
  6    11 ms   core4.fra.hetzner.com
  7     5 ms   amsix-gw.hetzner.com
  8     5 ms   core50.ams.hetzner.com
  9    11 ms   core4.fra.hetzner.com
 10    13 ms   core11.nbg1.hetzner.com
 12    13 ms   nbg1-speed.hetzner.com
 

Latency ziet er prima uit, geen packet loss. Toch haal ik zonder VPN consistent ~1 MB/s, met Surfshark VPN (NL-server) 60-90 MB/s — over meerdere dagen en tijdstippen getest.

Een paar vragen:

  • Zit jij ook op Odido glasvezel?
  • Is dat via eigen Odido-infrastructuur of KPN WBA?
  • Zou je ook mijn testbestand willen proberen? Ik stuur je de URL graag via PM.

  • is een Top Poster
  • March 16, 2026

Weet je zeker dat je trace klopt? Hij zegt Tracing route to nbg1-speed.hetzner.com dat is niet fsn1-speed.hetzner.com 😉

Zit jij ook op Odido glasvezel?

​​​​​​

Jaa ook op Glas van Odido, het is Odido infra. Ik kan later nog eens van een WBA verbinding testen,

Zou je ook mijn testbestand willen proberen? Ik stuur je de URL graag via PM.

Het is sinds kort niet meer mogelijk om hier PM te sturen, kan je de link hier delen?

Sinds wanneer merk je dit probleem? 


  • Auteur
  • is een Top Poster
  • March 16, 2026

@svenvg93 Goede opmerking over de traceroute — je hebt gelijk, dat was inderdaad naar nbg1 en niet fsn1. Mijn excuses voor de verwarring.

Interessant dat jij op eigen Odido-infrastructuur zit en wel goede snelheden haalt. Ik heb net mijn ONT-kastje gecheckt: het is een Huawei OptiXstar HN8010Ts-20 (XGS-PON). Dat is KPN WBA-infrastructuur.

Mogelijk verklaart dat het verschil tussen onze ervaringen. Het probleem zou dan specifiek kunnen spelen op het KPN WBA-netwerk dat Odido gebruikt, in plaats van op de eigen Odido-infrastructuur.

Ik merk het probleem al een tijdje — het is niet iets van de laatste dagen maar al enkele weken. En het lijkt consistent op elk tijdstip van de dag.

Zou je de test ook kunnen uitvoeren vanaf een WBA-verbinding als je daar toegang toe hebt? Dat zou veel verduidelijken.

De testlink op mijn weberver: https://hosting.inxpact.nl/testfile-100mb.bin


  • Auteur
  • is een Top Poster
  • March 16, 2026

Bij KPN WBA loopt het verkeer via meer schakels dan bij eigen Odido-infrastructuur — met name een overdrachtspoint tussen KPN en Odido. Mogelijk zit daar een bottleneck, bijvoorbeeld door onvoldoende ingekochte capaciteit. Een VPN zou die bottleneck mogelijk omzeilen via een andere route?

Dit is vooralsnog een theorie, maar het zou kunnen verklaren waarom jij geen problemen ervaart en ik wel. Ongeacht de oorzaak haal ik in de praktijk ~1 MB/s op een 1 Gbps abonnement...


  • is een Top Poster
  • March 16, 2026

Interessant dat jij op eigen Odido-infrastructuur zit en wel goede snelheden haalt. Ik heb net mijn ONT-kastje gecheckt: het is een Huawei OptiXstar HN8010Ts-20 (XGS-PON). Dat is KPN WBA-infrastructuur.

Als je de Huawei ONT hebt, zit je ook Odido-infrastructuur. Bij KPN WBA wordt de Genexis of Nokia ONT gebruikt van KPN WBA. 

Bij KPN WBA loopt het verkeer via meer schakels dan bij eigen Odido-infrastructuur — met name een overdrachtspoint tussen KPN en Odido. Mogelijk zit daar een bottleneck, bijvoorbeeld door onvoldoende ingekochte capaciteit. Een VPN zou die bottleneck mogelijk omzeilen via een andere route?

Een VPN maakt niks uit voor de route in het KPN WBA netwerk. KPN WBA netwerk is eigen voornamelijk Laag 2 tot aan de interconnect tussen KPN WBA en Odido. Als daar niet genoeg capaciteit zou zijn zou alles traag zijn en niet alleen HTTP/HTTP Downloads. 

Als voor de tests op een Odido Glas 1G via KPN WBA

curl -o NUL https://fsn1-speed.hetzner.com/100MB.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 100M 100 100M 0 0 101M 0 --:--:-- --:--:-- --:--:-- 101M
curl -o NUL https://fsn1-speed.hetzner.com/10GB.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10.0G 100 10.0G 0 0 118M 0 0:01:26 0:01:26 --:--:-- 124M
mtr -z -c 1 --report-wide fsn1-speed.hetzner.com
Start: 2026-03-16T18:05:06+0100
HOST: un100p Loss% Snt Last Avg Best Wrst StDev
1. AS??? home 0.0% 1 1.1 1.1 1.1 1.1 0.0
2. AS50266 xx-xxx-254-92.ftth.glasoperator.nl 0.0% 1 3.2 3.2 3.2 3.2 0.0
3. AS??? 10.227.161.253 0.0% 1 4.1 4.1 4.1 4.1 0.0
4. AS??? 10.226.11.40 0.0% 1 4.2 4.2 4.2 4.2 0.0
5. AS24940 core50.ams.hetzner.com 0.0% 1 4.6 4.6 4.6 4.6 0.0
6. AS??? amsix-gw.hetzner.com 0.0% 1 4.2 4.2 4.2 4.2 0.0
7. AS24940 core50.ams.hetzner.com 0.0% 1 3.9 3.9 3.9 3.9 0.0
8. AS24940 core1.fra.hetzner.com 0.0% 1 9.8 9.8 9.8 9.8 0.0
9. AS24940 core24.fsn1.hetzner.com 0.0% 1 13.9 13.9 13.9 13.9 0.0
10. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
11. AS24940 fsn1-speed.hetzner.com 0.0% 1 13.9 13.9 13.9 13.9 0.0

En voor jouw test file:

curl -o NUL https://hosting.inxpact.nl/testfile-100mb.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 100M 100 100M 0 0 55.7M 0 0:00:01 0:00:01 --:--:-- 55.7M
mtr -z -c 1 --report-wide hosting.inxpact.nl
Start: 2026-03-16T18:06:36+0100
HOST: un100p Loss% Snt Last Avg Best Wrst StDev
1. AS??? home 0.0% 1 1.0 1.0 1.0 1.0 0.0
2. AS50266 xx-xxx-254-92.ftth.glasoperator.nl 0.0% 1 3.1 3.1 3.1 3.1 0.0
3. AS??? 10.227.173.213 0.0% 1 4.1 4.1 4.1 4.1 0.0
4. AS??? 10.226.11.37 0.0% 1 3.9 3.9 3.9 3.9 0.0
5. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
6. AS??? amsix-tc2.fundaments.nl 0.0% 1 5.4 5.4 5.4 5.4 0.0
7. AS20559 185.113.84.208 0.0% 1 5.1 5.1 5.1 5.1 0.0
8. AS20559 inxpact.oxilion.cloud 0.0% 1 5.0 5.0 5.0 5.0 0.0

 


  • is een Top Poster
  • March 16, 2026

Als aanvulling: een HTTP-download zoals hier getest wordt, is in principe vergelijkbaar met een normale Ookla Speedtest. Uiteindelijk bestaat het verkeer in beide gevallen gewoon uit TCP-verkeer.

In mijn geval maakt het niet uit waar ik tegen aan test, het resultaat is altijd binnen de verwachting voor een 1G verbinding 

speedtest -s 52365

Speedtest by Ookla

Server: Odido - Amsterdam (id: 52365)
ISP: Odido Netherlands
Idle Latency: 3.89 ms (jitter: 0.21ms, low: 3.37ms, high: 4.15ms)
Download: 1038.76 Mbps (data used: 494.9 MB)
11.93 ms (jitter: 0.80ms, low: 7.01ms, high: 21.58ms)
Upload: 1012.16 Mbps (data used: 770.6 MB)
3.56 ms (jitter: 0.21ms, low: 3.21ms, high: 6.54ms)
Packet Loss: 0.0%
speedtest -s 61186

Speedtest by Ookla

Server: KPN B.V. - Amstelveen (id: 61186)
ISP: Odido Netherlands
Idle Latency: 4.90 ms (jitter: 0.21ms, low: 4.47ms, high: 5.02ms)
Download: 1047.17 Mbps (data used: 808.4 MB)
140.74 ms (jitter: 50.26ms, low: 5.51ms, high: 484.96ms)
Upload: 972.04 Mbps (data used: 1.0 GB)
4.05 ms (jitter: 0.25ms, low: 3.43ms, high: 5.58ms)
Packet Loss: 0.0%
speedtest -s 35692

Speedtest by Ookla

Server: Clouvider Ltd - Frankfurt am Main (id: 35692)
ISP: Odido Netherlands
Idle Latency: 11.06 ms (jitter: 0.64ms, low: 10.42ms, high: 11.81ms)
Download: 1036.45 Mbps (data used: 931.8 MB)
139.44 ms (jitter: 44.81ms, low: 11.30ms, high: 217.21ms)
Upload: 844.22 Mbps (data used: 1.1 GB)
10.63 ms (jitter: 0.25ms, low: 10.29ms, high: 12.13ms)
Packet Loss: 0.0%
speedtest -s 62493

Speedtest by Ookla

Server: ORANGE FRANCE - Paris (id: 62493)
ISP: Odido Netherlands
Idle Latency: 13.26 ms (jitter: 0.20ms, low: 12.98ms, high: 13.50ms)
Download: 1052.55 Mbps (data used: 944.1 MB)
123.73 ms (jitter: 38.53ms, low: 12.96ms, high: 195.12ms)
Upload: 789.91 Mbps (data used: 899.4 MB)
13.21 ms (jitter: 0.25ms, low: 12.91ms, high: 15.31ms)
Packet Loss: Not available.

Wat zijn de resultaten als je een zelfde soort test doet naar verschillende servers buiten het Odido netwerk. Kan eventueel eenzelfde probleem zijn als hier een tijd geleden: 

 


  • Auteur
  • is een Top Poster
  • March 16, 2026

Dank voor de link naar dat topic — dat beschrijft exact hetzelfde patroon: speedtest goed, maar zodra je de Odido backbone verlaat lage downloadsnelheden.

Een opmerking in dat topic vond ik opvallend: iemand zag dat na het wisselen van router (en dus MAC-adres) de snelheid plots wel goed was. Dat zou kunnen betekenen dat het probleem gekoppeld is aan een specifieke aansluiting of configuratie, en niet aan een algemeen netwerkprobleem.

Als dat het geval is bij mij ook, zou dat verklaren waarom anderen op Odido geen problemen ervaren en ik wel — en zou het ook oplosbaar moeten zijn aan Odido's kant.

Hieronder de traceroutes zonder VPN naar de gevraagde servers. Routes zijn schoon, lage latency, geen packet loss — routing is niet het probleem.

fsn1-speed.hetzner.com
 1  192.168.2.1                          <1ms
 2  ftth.glasoperator.nl [82.174.184.1]   3ms
 3  10.227.135.139                        6ms
 4  10.226.9.22                           5ms
 5  core50.ams.hetzner.com                5ms
 6  amsix-gw.hetzner.com                  4ms
 7  core50.ams.hetzner.com                5ms
 8  core5.fra.hetzner.com                10ms
 9  core23.fsn1.hetzner.com              15ms
11  fsn1-speed.hetzner.com               15ms
 

hosting.inxpact.nl (eigen server, Oxilion)

 1  192.168.2.1                          <1ms
 2  ftth.glasoperator.nl [82.174.184.1]   3ms
 3  10.227.135.139                        5ms
 4  10.226.9.22                           5ms
 5  185.113.84.208                        6ms
 6  amsix-tc2.fundaments.nl               6ms
 7  185.113.84.208                        6ms
 8  inxpact.oxilion.cloud                 6ms
 

1.1.1.1 (Cloudflare)

 1  192.168.2.1                          <1ms
 2  ftth.glasoperator.nl [82.174.184.1]   3ms
 3  10.227.135.139                        6ms
 4  10.226.9.22                           5ms
 5  141.101.65.141                        6ms
 6  ams-ix.as13335.net                    6ms
 7  141.101.65.141                        6ms
 8  one.one.one.one                       6ms
 

google.com

 1  192.168.2.1                          <1ms
 2  ftth.glasoperator.nl [82.174.184.1]   3ms
 3  10.227.135.139                        6ms
 4  10.226.9.22                           5ms
 5  172.253.66.253                        7ms
 6  72.14.209.208                         6ms
 7  172.253.66.253                        7ms
 8  209.85.250.123                        5ms
 9  lhr25s32-in-f14.1e100.net             5ms
```

@Tommie van Odido Kunnen jullie voor mij uitzoeken of er iets specifieks op mijn aansluiting of configuratie staat dat dit veroorzaakt?

Ik heb ondertussen een TP-Link ER605 besteld om te testen of een andere router met een ander MAC-adres het probleem oplost. Ik zal de resultaten tzt hier delen. Voor het instellen van de ER605 heb ik de PPPoE-credentials van mijn aansluiting nodig. Kan iemand vertellen waar ik die kan vinden, of werkt de Odido-aansluiting via DHCP zonder credentials?


  • Auteur
  • is een Top Poster
  • March 16, 2026

@Tommie van Odido 
Aanvullende informatie: er is enige tijd geleden een nieuw ONT-kastje geplaatst door een Odido-monteur omdat het oude defect was. Het is mogelijk dat het probleem is ontstaan na die vervanging. Kunnen jullie controleren of het nieuwe ONT correct is geregistreerd en het juiste profiel heeft?


  • is een Top Poster
  • March 16, 2026

@jjonker In een trace ga je dit probleem niet zien. Kan je eens wat speedtesten doen naar verschillende servers en de screenshots hier posten. Dan weten we zeker dat het probleem hetzelfde is. Het probleem in het gelinkte topic was niet klant specifiek maar een generiek netwerk probleem wat sommige klanten in een regio trof. 

Wegens de recente gebeurtenissen kan hier alleen nog algemeen geholpen worden ​@Tommie van Odido. Na het doen van de testen, moet je contact opnemen met klantenservice, dan kunnen zij je verder opweg helpen! 


  • Auteur
  • is een Top Poster
  • March 16, 2026

https://www.speedtest.net/

Zonder VPN:

  • KPN server: 238 / 945
  • Frankfurt Tele AG: 13 / 944
  • MatrixDATA Harderwijk: 50 / 940
  • Previder BV Hengelo: 48 / 946

Met VPN:

  • KPN server: 891 / 903
  • Frankfurt Tele AG:889 / 903
  • MatrixDATA Harderwijk: 891 / 903
  • Previder BV Hengelo: 894 / 902

Dus: Upload altijd prima (~940 Mbps), download gethrotteld zonder VPN

Lijkt me dus duidelijk dat er een probleem is met mij verbinding?

Contact opnemen met de klantenservice: Ik heb zowel iemand van de 1e als (na veel aandringen) iemand van de 2e lijn gesproken en die hadden geen idee waar ik het over en geen idee wat er aan de hand kon zijn en ik moest dan maar een klacht indienen want dan werd er wellicht beter naar gekeken. Dus ik heb ook meteen een formele klacht per brief ingediend. Ik hoop dat ​@Tommie van Odido (of iemand anders van Odido) deze gegevens kan gebruiken om mijn aansluiting te onderzoeken.

 


Tommie van Odido
Moderator
Forum|alt.badge.img+13
  • Moderator | Internet + TV
  • March 17, 2026

Hey ​@jjonker, het zat me toch niet helemaal lekker om dit te laten liggen, daarom heb ik met de aangeleverde testen toch het een en ander laten onderzoeken voor je. Op basis van onze eigen testen hebben we een aanpassing gedaan in de wijkcentrale. Als het goed is zou het nu beter moeten zijn. Kan je dat eens controleren?


  • Auteur
  • is een Top Poster
  • March 17, 2026

Het probleem is opgelost! Getest zonder VPN:

- HTTP download: ~99 MB/s (was ~1.8 MB/s)
- Speedtest Frankfurt: 945 Mbps (was 13 Mbps)
- SFTP van webserver naar NAS: ~102 MB/s (was ~1 MB/s)

Alles werkt nu zoals het hoort.

@svenvg93  Heel erg bedankt voor je tijd, meekijken en hulp. Je technische inzicht heeft er echt aan bijgedragen dat het probleem boven water kwam. Dat waardeer ik zeer.

@Tommie van Odido 
Dank je wel dat je het toch niet hebt laten liggen en de moeite hebt genomen om dit te laten onderzoeken en op te lossen. Dat stel ik zeer op prijs.

Ik wil wel voorzichtig opmerken dat het jammer is dat de klantenservice — zowel eerste als tweede lijn — hier niets mee kon. Zij gaven aan geen weet te hebben van dit soort problemen en verwezen mij door om een klacht in te dienen. Dat had wellicht beter gekund en sneller tot een oplossing geleid.

ik heb ook een formele klacht per aangetekende brief ingediend bij Odido. Nu het probleem is opgelost, zou je intern kunnen aangeven dat deze klacht als afgehandeld beschouwd kan worden?


  • Auteur
  • is een Top Poster
  • March 17, 2026

@Tommie van Odido 
Toch nog even een vraag als het mag, voor mij en eventueel voor andere in de toekomst: Kun je aangeven wat er precies technisch mis was in de wijkcentrale? En was dat niet iets wat de helpdesk had kunnen zien / testen / merken? 


  • is een Top Poster
  • March 17, 2026

Graag gedaan! Fijn om te horen dat alles nu weer goed werkt 😁.