Доброго времени суток. Ситуация. В феврале у меня появилась проблема с тем, что не открываются некоторые сайты, которые до этого спокойно работали (steam, ubisoft и тд). Провайдер отвечал, что с его стороны никаких блокировок нет, хотя VPN спокойно всё открывал. Решил поменять DNS сервер (с 8-ок) через DNSJumper. Выставил 1.1.1.1 и на неделю+ всё нормализовалось.

Затем началась дичь. Любой сайт стал открываться спустя 5-10 секунд. На сервера в Дискорде так же пускало через время. Короче, появилась странная задержка. Причем вот какое наблюдение: иногда я на сайт захожу моментально, а иногда на него же - с этой задержкой. Это не зависит от времени суток и нагруженности сети. Как будто я попадаю в цикл какой-то.

Что я делал, чтобы пофиксить:

• чистка вирусов (AVZ, Cure It)
• восстановление сети через cmd (dnsflush)
• выбор старого DNS (8-ки)
• использование DNSCrypt, WARP и прочих софтин
• смена роутера

Результат один - чинится на 10 минут, затем всё по новой.
Местонахождение - юг России, провайдер один (AVANTA)

Подскажите, что это всё-таки может быть? Винду сейчас сносить боль, переносить 500+ гб важной инфы в облако не получится (в данный момент).

Если сделать ipconfig /flushdns, затем nslookup <какой-то сайт>, как быстро ответ выдает?

Мгновенно

Тогда может и не в днс проблема.
Посмотрите браузером через средства разработчика, если не ошибаюсь, вкладка сеть. Там можно отследить какой элемент сколько загружается.
Если копать ещё глубже, можно собрать дамп Wireshark’ом, если кто-то тут возьмётся проанализировать его.
У вас интернет роутер раздает? С других устройств такая же проблема?

Да, раздает роутер. С других устройств проблему не наблюдал, но из других устройств только 2 смартфона)

По загрузке просто вот так пишет и всё, остальные элементы в норме по времени (грузил VK | Herzlich Willkommen)

Ну если уж подозрения на проблемы с dns, то как грузятся сайты по ip? Например https://1.1.1.1/

так же, как и остальные… бывает мгновенно, а бывает просадка до 10 секунд, зависит от… хз чего

Слышал когда не будь про такой в винде параметр EnablePMTUDiscovery
вот он может выключить нэт, то есть какое то одно плохое соединение, потащит за собой все остальные, скорость будет падать для всех соединений, находится он по этому пути в реестре
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters
попробуй выставить 0 и перезагрузить комп и понаблюдай потом за работой.
Это не выход из ситуации, так, для проверки. Есть такое понятие, как настройка сетевого стёка, что обычно практически никто этого не знает и никогда не учитывает, ищут проблемы далеко, хотя они всегда навиду.
И 500 гигов на диске С, это конечно жесть, на диске С должна быть только винда и проги и больше ничего, для игр отдельно диск ssd, для всего остального отдельно должен быть диск )

Сколько тратится усилий только, чтобы не запускать шарк
В шарке же все видно, чего гадать
Если не можете сами, кидайте дамп. Посмотрим всем народом
Все посторонние источники трафика и антивирусы отключить.
Сделать ipconfig /flushdns
Броузер запустить. Кэш почистить. Нажать старт в шарке. Зайти на тупящий сайт. Подождать окончания. Остановить шарк. Сохранить дамп

не знаю, так ли я сделал, но вот
111.pcapng (6,1 МБ)

Этого параметра по данному пути нет вообще

image1096×386 30.5 KB

UPD. Ввел его сам (DWORD), ничего не изменилось

Отдаётся днс забаненный ip и нормальные и пока браузер перебирает ip, сайт тупит

Сразу могу сказать, что DNS в броузере DoH, прямых запросов к DNS нет, поэтому меняй - не меняй в системе - разницы не будет
По дампу видны регулярные потери пакетов, которые вызывают ретрансмиссии tcp
На вашем месте я бы хорошенько проверил соединение к провайдеру
Для начала погонять mtr до разных ресурсов. Посмотреть loss rate.
Далее с какими-нибудь сервером в инете прогнать iperf туда-обратно по udp с ограничением полосы до , скажем, 10M. Посмотреть на потери.
Прогнать iperf tcp туда-обратно
Если будут значительные потери, подключить кабель к компу без роутера и повторить

iperf3 -4 -p 5200 -u -b 10M -c iperf3.moji.fr
iperf3 -4 -p 5200 -u -b 10M -c iperf3.moji.fr -R
iperf3 -4 -p 5200 -c iperf3.moji.fr
iperf3 -4 -p 5200 -c iperf3.moji.fr -R

Такие проблемы бывают на кабельных провайдерах по разным причинам. Например, проблемы с кабелем. Еще бывают проблемы с согласованием линка на 100 mbit. На разных концах разный дуплекс
Чем подключен провайдер ? Ethernet, docsis, pon ?

Еще вопрос по поводу MTU. Судя по размеру пакетов, mtu у вас 1440. Чем вызван такой размер ? Это подключение напрямую к провайдеру или через VPN ?

Я тоже живу в Ростове на Дону, у меня на TTK вечером потери тоже 10+% и на tcp и на udp

Посмотрел провайдер AVANTA. Как я понимаю там pon ?
pon - вообще такая себе технология. Ее продвигают как оптику, но это не та самая оптика от и до. На ней висит туча абонентов через сплиттеры. Достаточно трэшовый вариант. Об этом много писали. Но нужны конкретные замеры в разных ситуациях, особенно в случае проблем

Непонятно. Посмотри, например, tcp.stream eq 23 в дампе — компьютер, по какой-то причине, не стал отвечать на SYN/ACK после совершения SYN.

@MOVIESTRAIFE, у вас несколько сетевых интерфейсов на компьютере?

К сожалению, мои познания по сетке весьма ограничены, так что, если возможно, распишите алгоритм действий / скиньте инструкцию, пожалуйста по действиям, которые мне нужно совершать.

Как я спросил у провайдера, подключение через pon.
Подключение было напрямую к провайдеру.

Если кабелем подключить вместо wifi, что-то меняется ?
Вижу virtualbox установлен. Если из виртуалки в момент проблем попробовать, тоже самое ? Желательно перевести виртуалку в режим сети мост (bridge)

Проверить смогу только вечером.
Но пока что вот какой момент. 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.

нет такого правила, все зависит от прова