Проверить смогу только вечером.
Но пока что вот какой момент. MTU в винде стоит 1500, в роутере (TP-Link Archer AX50) 1480, но спидгайд выдает что у меня 1440. Что может влиять на это значение, кроме VPN?
дополняю после разговора с ним: curl у него тоже долго висит в момент резолва домена, но nslookup срабатывает моментально, файлы с браузера скачиваются быстро. После “сброса сети” у него винда перестала грузиться и ушла в режим восстановления, после него всё же включилась, на SSD нашлись битые и медленные сектора (у меня подозрение что повредились какие-то системные файлы)
Тогда ему стоит начинать с загрузки с образа WinPE или linux, и потестить тоже самое оттуда. Чтобы исключить проблемы основной системы.
Любую сложную систему надо разделять на звенья, и тестировать каждое отдельно, чтобы локализовать проблему
Другая ОС, другое подключение (кабель, wifi)
Это может быть и битая система, и плохие/старые драйвера на wifi, и плохо подобранные параметры точки доступа (40 Мгц на 2.4, когда есть 30 соседей), и плохой провайдер с его PONом
Я не удивлюсь, если в роутере жестко задана коррекция MSS, и на самом деле это не MTU, а MSS
Заводские прошивки умеют удивлять
Первым делом надо сделать tracert -w 1 -d 1.1.1.1
Чтобы понять куда вообще идет трафик. На провайдера или что-то еще там есть
Если это голый провайдер, то далее надо выяснить идет ли ограничение по MSS или по MTU.
Надо выполнить частично процедуру path MTU discovery.
В голой винде без сторонних средств это можно сделать несколькими командами ping
Суть в том, чтобы послать несколько проб icmp пакетов разной длины с флагом dont fragment с разным TTL. TTL из диапазона 1 и 2 для начала. 1 - это сам роутер, 2 - это уже провайдер
Длину пакета начать с 1472. Это соответствует MTU 1500.
Потом сокращать до 1452 (MTU 1480) и 1412 (MTU 1440)
Значимый результат будет наличие или отсутствие ошибки “Packet needs to be fragmented but DF set” (на русский сами переведете).
Если ошибка есть, значит роутер на указанном хопе не пропускает пакеты означенной длины.
Вот это по идее должно точно сработать (без ошибки DF)
ping -w 1 -n 1 -f -i 1 -l 1472 1.1.1.1
Далее :
ping -w 1 -n 1 -f -i 2 -l 1472 1.1.1.1
ping -w 1 -n 1 -f -i 2 -l 1453 1.1.1.1
ping -w 1 -n 1 -f -i 2 -l 1452 1.1.1.1
ping -w 1 -n 1 -f -i 2 -l 1413 1.1.1.1
ping -w 1 -n 1 -f -i 2 -l 1412 1.1.1.1
Так мы выясним MTU. И если он не 1440, а больше, то ограничение идет по MSS, и скорее всего это роутер так делает с его прошивкой
MSS это maximum segment size, и относится к TCP. часто на роутерах делается clamp mss, чтобы TCP не зависал при неработающем path mtu discovery
traceroute шлет icmp, потому MSS к нему никак не относится
Пример того, что творит USB модем huawei E8372
-A PREROUTING -i wan0 -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m tcpmss --mss 1460:1500 -j TCPMSS --set-mss 1460
-A PREROUTING -i wan0 -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN,ACK -m tcpmss --mss 1460:1500 -j TCPMSS --set-mss 1460
-A POSTROUTING -o wan0 -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m tcpmss --mss 1460:1500 -j TCPMSS --set-mss 1460
-A POSTROUTING -o wan0 -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN,ACK -m tcpmss --mss 1460:1500 -j TCPMSS --set-mss 1460
Если http://www.speedguide.net:8080 показывает mtu 1440, а на компе 1500 и в роуторе 1480, то значит включён vpn, поэтому плохо с задержками и работает )
ВПН выключен 100%
MTU проще определить этой утилиткой mturoute.exe - official site
А вообще, если у вас Pon, то провайдер вам подаёт канал через туннельное соединение, соответственно MTU будет ниже 1500. У меня Pon от Ростелекома через pppoe, MTU 1492. Ваши 1480 возможно выдает вам провайдер.
Но думаю проблема всё-таки в вашей системе. MTU 1400 - возможно прокси в браузере, плагин или какой-то софт на подобии GoodbyDPI. Speedguide показывает ваш внешний IP?
Поудаляйте с системы всякие обходы блокировок. Поставьте другой браузер, которым не пользовались, проверьте на дефолтных настройках.
И как уже писали выше, проверьте на WinPE.
нет такого правила, все зависит от прова