Кратко — вы всё правильно думаете: локальный сегмент (кабель, NIC, роутер) скорее всего в порядке, а «скачки» пинга почти всегда вызваны проблемами маршрутизации/перегрузкой у провайдера / между AS или поведением промежуточных роутеров (особенно в мобильных сетях). Чтобы точно локализовать узел с проблемой и собрать данные для техподдержки, нужно правильно выполнить трассировку и собрать набор логов. Ниже — пошагово, какие команды запускать, с какими параметрами и что из результата фиксировать и отправлять оператору.
1) Что и почему проверять (список целей)
- Локальный шлюз/роутер (обычно 192.168.x.1) — чтобы убедиться, что задержки не на вашей LAN.
- WAN‑IP роутера / модема (виден в web‑интерфейсе или в статусе) — проверяем соединение с сетью оператора.
- Первый hop провайдера (первый публичный IP после вашего оборудования).
- Несколько промежуточных хопов вплоть до целевого игрового сервера.
- Игровой сервер / matchmaker. В CS2/Valve можно увидеть IP сервера через консоль команды status или смотреть текущие соединения процесса (netstat).
- Общие целевые «контроли»: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare) — для сравнения стабильности до известных провайдеров.
2) Как найти IP игрового сервера
- В CS2 открыть консоль и выполнить команду status — в выводе обычно виден ip:port сервера.
- Или пока идёт матч, запустить в Windows: netstat -n -p udp | findstr :270 (или netstat -anb и найти cs2/steam connection) — это покажет IP/порт, с которым клиент общается.
Снимите IP и используйте его в трассировках.
3) Команды и рекомендованные параметры
A) tracert (Windows)
- tracert -d -h 30 -w 1000 <IP_или_хост>
- -d — не делать обратное разрешение DNS (быстрее, чище).
- -h 30 — max hops.
- -w 1000 — таймаут в ms (можно увеличить, если сеть медленная).
- Что фиксировать: RTT всех трёх попыток на каждом хопе, общее поведение (высокие значения, большие скачки).
B) pathping (Windows)
- pathping -n -q 100 -w 1000 <IP>
- -n — без DNS.
- -q 100 — число запросов на каждый хоп (чем больше — тем точнее статистика); можно 50–200.
- -w 1000 — таймаут в ms.
- pathping даёт суммарную статистику потерь и RTT по каждому хопу за время теста. Очень полезен для выявления потерей на конкретном узле.
C) WinMTR (Windows GUI) / mtr (Linux/WSL)
- WinMTR: в поле Host ставите IP сервера, количество пакетов — 1000–5000, интервал 1 с; запускаете на 5–30 минут (если лаги редкие — дольше).
- mtr (WSL/Cygwin/Linux): mtr -n -c 2000 --report-wide <IP>
- -n — без DNS, -c — число циклов, --report-wide даёт расширенный отчёт.
- Что фиксировать: % потерь на каждом хопе, avg/min/max RTT, стабильность (джиттер).
D) TCP/UDP трассировка (важно: ICMP может деприоритизироваться)
- Многие маршрутизаторы отдают приоритет TCP/UDP трафику, а ICMP‑ответы игнорируют/ограничивают, поэтому классические tracert/WinMTR (ICMP) могут показывать «ложную» потерю только на промежуточных роутерах, несмотря на то, что следующий хоп/конечный узел в порядке.
- TCP traceroute / tcpping: на Linux tcptraceroute <IP> <порт_игры> или hping3 -S -p <порт> --traceroute <IP>.
- На Windows можно использовать tcping.exe (tcping <IP> <порт>) или nping (с пакетом Nmap) для проверки TCP‑пинга на порт игры (обычно 27005/27015 для Valve).
- Рекомендуется проверять на порту игрового сервера (UDP или TCP в зависимости от игры), чтобы эмулировать реальный игровой трафик.
E) Пинга с отметкой времени (для корреляции со "лагами" в игре)
- PowerShell, пример:
while ($true) {
$t=(Get-Date).ToString("o");
$r=(Test-Connection -Count 1 -ComputerName 8.8.8.8).ResponseTime;
Write-Output "$t $r ms";
Start-Sleep -Seconds 1
}
- Или обычный ping -t <IP> и параллельно фиксировать время (но лучше PowerShell для точного лога).
F) Захват пакетов (Wireshark)
- Сделайте pcap во время проявления лагов, фильтруйте по IP игрового сервера (ip.addr == x.x.x.x) и смотрите TCP retransmissions, UDP retransmits (если есть), Out‑of‑order, duplicate ACKs, RTT variation.
- Wireshark pcap — очень ценный артефакт для техподдержки.
4) Как долго и с какими интервалами тестировать
- Для WinMTR/mtr: как минимум 5–15 минут; при редких спайках — до 30–60 минут.
- Для pathping: запуск 1–3 минуты не даст статистики — запускайте минимум 1–2 минуты с -q >= 50.
- Для ping: непрерывно 1–5 минут и дольше при необходимости; сохраните логи.
5) Как интерпретировать результаты (что считать признаком проблемы)
- Реальная проблема на узле: если на каком‑то хопе начинается постоянная потеря пакетов и она сохраняется на всех последующих хопах вплоть до цели — проблема на этом сегменте (и её место нужно сообщить провайдеру).
- Декорация ICMP: когда на одном хопе видно 50–100% loss, но последующие хопы показывают 0% и нормальные RTT — часто это означает, что роутер на том хопе просто не отвечает на ICMP, а не теряет ваш реальный трафик. Такое поведение НЕ всегда означает проблему, и провайдер может проигнорировать это как «норму».
- Прыгающий RTT/jitter: если RTT резко и периодически увеличивается на одном/нескольких хопах и это отражается в увеличении RTT до конечного сервера — это реальный источник лагов.
- Асимметричный маршрут/возвратный путь: пинг и трассировка измеряют путь туда; возвратный маршрут может отличаться и быть проблемным. Если на месте «любовного» пинга нет потерь, но у вас в игре лаги — попросите оператора проверить маршруты в оба конца.
6) Что собирать и отправлять техподдержке оператора
Подготовьте и приложите:
- WinMTR / mtr отчёт (сохранённый в текстовом виде) до игрового сервера (IP) и до пары контрольных адресов (8.8.8.8, 1.1.1.1).
- pathping <IP> (полный вывод).
- tracert -d <IP> (полный вывод).
- Логи ping с timestamp (с периодом 1 с) к игровому серверу и к 8.8.8.8 за время проявления проблемы.
- Wireshark pcap во время лагов (фильтрован по исходящему/целевому IP).
- Скриншот/вывод status из консоли CS2, показывающий IP сервера и время проявления лагов.
- Ваш внешний WAN IP (router status), время (UTC и локальное) когда происходили лаги, длительность и частота (например: "скачки каждые 2–3 минуты, по 1–2 сек").
- Логи/скриншоты из интерфейса модема LTE: уровень сигнала (RSRP/RSRQ/SINR), имя APN, cell id / eNodeB (если доступно). Для мобильной сети это сильно помогает — часто проблема в перегруженной соте.
- Уточнить: используете ли CGNAT (часто у мобильных операторов) — WAN IP частный или публичный; если частный — сообщите это (оператор должен знать).
7) Дополнительные тесты и советы
- Сравните результаты в разное время суток (утро/пик/ночь) — мобильные сети сильно зависят от нагрузки.
- Попробуйте подключиться через VPN (низколатентный игровой VPN или любой другой) и посмотреть, сохраняются ли скачки. Если VPN стабилизирует — это почти однозначно проблема маршрутизации/пиров провайдера.
- Проверьте фоновые загрузки/обновления на ПК и роутере, QoS, лимиты/цепочки фильтрации.
- Обновите прошивку модема/роутера, драйвер сетевой карты (Realtek).
- Можно временно поднять MTU (обычно не нужно), но проверьте фрагментацию: ping -f -l <size> для теста (Windows ping).
- Если проблема у провайдера/между AS — заходите в службу поддержки с полным набором логов (см. пункт 6) и просите трассировку трассировки маршрута (BGP/peering check) со стороны их сети до IP игрового сервера.
8) Примерный список команд для выполнения (шаблон)
- tracert -d -h 30 -w 1000 <IP_game>
- pathping -n -q 100 -w 1000 <IP_game>
- WinMTR -> Host = <IP_game>, Packets = 2000–5000, Interval = 1s -> Save report (TXT/CSV)
- mtr -n -c 2000 --report-wide <IP_game> (в WSL)
- tcptraceroute <IP_game> <порт_игры> (или hping3/tcping)
- PowerShell timestamped ping (см. выше) к <IP_game> и к 8.8.8.8
- netstat -anb > netstat_cs2.txt во время игры (чтобы зафиксировать IP/порт)
9) Что можно ожидать от техподдержки оператора
- По логам они должны увидеть проблемный hop / узел / сегмент и выполнить проверку маршрута / peering / congested link. В мобильной сети они дополнительно проверят загрузку базовой станции и качество радиосигнала.
- Если проблема — межоператорская маршрутизация, их ответ может занять время и потребовать эскалации к peering team.
10) Быстрое руководство по интерпретации итогов (что отправлять и на что обратить внимание)
- Если WinMTR показывает потерю пакетов на хопе X и потери доходят до цели — это «реальная» потеря; отправьте отчёт.
- Если хоп X показывает 100% loss, но следующие хопы OK — это, вероятно, деприоритизация ICMP (не критично).
- Если RTT резко поднимается у хопа Y и затем остаётся высоким — именно там добавляется задержка.
- Укажите точные времена (UTC) всех запусков тестов и момент/скрин ин‑иге, когда был лаг.
Если хотите — могу:
- Прислать готовый бат/ps скрипт для автоматического сбора ping+tracert+WinMTR (лог в файл).
- Помочь разобрать конкретный WinMTR/pathping/tracert вывод — пришлите файлы/скриншоты, и я подскажу, где проблема вероятнее всего.
Нужен ли вам скрипт/инструкция для автоматизированного сбора логов (PowerShell/BAT) или разбор конкретного вывода — пришлите результаты, разберём вместе.