Потери пакетов в домашней сети: диагностика и устранение

Потери пакетов в домашней сети чаще всего означают проблему на локальном сегменте — повреждённый кабель/порт, конфликт настроек или перегрузка/ошибка сетевого оборудования; чтобы диагностировать и устранить, нужно последовательно изолировать узлы, снять трассировки (mtr/WinMTR, pktmon/netsh), собрать счётчики интерфейсов и проверить прямое подключение к модему. Если трассировка показывает начало потерь у вас, а у соседей на той же улице тоже есть симптомы — подготовьте логи и требуйте у провайдера проверку физической линии/районного узла; ниже — подробная пошаговая инструкция с командами и чек‑листом.

Содержание

• Контекст проблемы и краткая диагностика
• Быстрая проверка (что сделать прямо сейчас)
• Подробная диагностика локальной сети: команды и анализ
• Тесты и рекомендации для Wi‑Fi и Ethernet
• Как читать трассировку и где локализовать потери
• Частые аппаратные и конфигурационные причины и их устранение
• Сбор доказательств и взаимодействие с провайдером/соседями
• Практический чек‑лист по приоритетным действиям
• Источники
• Заключение

Контекст проблемы и краткая диагностика

Вы описали классическую ситуацию: потери пакетов появляются и по Wi‑Fi, и по Ethernet; трассировка указывает на начало потерь «на вашем участке», вы меняли роутер — без эффекта; провайдер «видит нормально», но похожая проблема у соседей. Что это может значить?

• Риск №1 — физический/канальный уровень (кабель, коннектор, подъездная линия, переходы) или сетевое оборудование между домом и распределителем: повреждение линии или плохой контакт даёт оба эффекта (Wi‑Fi и кабель), особенно если соседям тоже плохо.
• Риск №2 — общая конфигурация/сервис в вашем доме (например, неправильно работающий коммутатор, питание, PLC/Powerline адаптеры, общий бридж), которая влияет на все устройства.
• Риск №3 — перегрузка/потеря пакетов при пиковых нагрузках (bufferbloat, NAT/сложные правила QoS), когда пакеты сбрасываются под нагрузкой.

Первые шаги — доказать, что «потери начинаются у вас», и собрать reproducible‑логи (mtr/WinMTR, pktmon/netsh, pcap), чтобы корректно аргументировать претензию провайдеру или сменить штатное сетевое оборудование.

Быстрая проверка (что сделать прямо сейчас)

Эти действия займут 10–60 минут и дадут быстрые данные.

1. Проверка на всех устройствах. Убедитесь, что потеря пакетов наблюдается на 2+ устройствах (ПК, ноут, телефон). Если только на одном — проблема на нём.
2. Подключитесь напрямую к модему/ONT, минуя роутер (если возможно). Если потери исчезают — виноват роутер/локальная сеть. Если остаются — проблема на линии/у провайдера.
3. Запустите непрерывный ping к шлюзу и в интернет (пример Windows и Linux):

# Windows
ping -t 192.168.1.1
ping -n 200 8.8.8.8

# Linux / macOS
ping 192.168.1.1
ping -c 200 8.8.8.8

Интерпретация: потеря уже на шлюзе (первый hop) → локально; потеря только в интернет‑hop → возможно провайдер/последующий узел.

4. Быстрая трассировка (Windows/Linux):

# Windows
tracert -d 8.8.8.8
pathping 8.8.8.8

# Linux
mtr --report 8.8.8.8

5. Проверьте показатели интерфейса (Windows PowerShell / Linux):

Get-NetAdapterStatistics -Name "Ethernet"

ip -s link show eth0
ethtool -S eth0
dmesg | grep -i eth

Если видите ошибки RX/TX, drops или CRC — это подтверждение физической/канальной проблемы.

(Для деталей по локальной диагностике в Windows смотрите рекомендации Microsoft: https://learn.microsoft.com/ru-ru/troubleshoot/windows-client/networking/diagnose-packet-loss)

Подробная диагностика локальной сети: команды и анализ

Цель — локализовать место сброса: NIC ⇢ домашняя проводка/коммутатор ⇢ роутер ⇢ провайдерский порт.

1. Соберите длительную трассировку mtr/WinMTR (5–10 минут, лучше 10+). Экспортируйте результат.

• WinMTR (Windows GUI) — оставьте 5–10 минут, затем Save TXT/CSV.
• Linux: mtr --report-wide --interval 1 --report-cycles 600 8.8.8.8 — сохраните вывод.

2. Замеры скорости и потерь в LAN: используйте iperf3 (на одном компьютере iperf3 -s, на другом iperf3 -c ).

• TCP тест покажет проблемы с пропускной способностью; UDP тест с флагом -u и -b позволит контролировать потерю UDP‑пакетов.

3. Захват трафика (pcap) для анализа retransmit/retry:

sudo tcpdump -i eth0 -w /tmp/capture.pcap
# или на Windows использовать pktmon / Wireshark

Для Windows можно использовать pktmon/netsh: https://learn.microsoft.com/ru-ru/troubleshoot/windows-client/networking/diagnose-packet-loss

Примеры команд pktmon/netsh:

pktmon start --capture --file pktmon.etl
# воспроизвести проблему
pktmon stop
pktmon pcapng pktmon.etl -o capture.pcapng

netsh trace start capture=yes tracefile=c:\temp\nettrace.etl
# воспроизвести
netsh trace stop

4. Проверьте ARP/дубликаты IP:

arp -a
ip neigh show

Дубликаты MAC/IP могут давать интермиттирующие потери.

5. Счётчики на коммутаторах и роутере: включите syslog, проверьте ошибки/флапы портов, CRC, collisions. Если у вас управляемый коммутатор — посмотрите port statistics.

6. Если используете PowerLine/PLC/USB‑адаптеры/мосты — временно отключите и проверьте.

Ссылки для понимания причин потерь и видов тестов: обзор причин и диагностик — Pandorafms https://pandorafms.com/blog/ru/packet-loss/ и кейсы с локальными ping‑тестами — CatoNetworks https://support.catonetworks.com/hc/ru/articles/360002598617-Устранение-неполадок-потери-пакетов-на-сайте-Socket

Тесты и рекомендации для Wi‑Fi и Ethernet

Wi‑Fi

• Проверьте RSSI / скорость соединения на клиенте (Windows: netsh wlan show interfaces; Linux: iw dev wlan0 link). Высокие ошибки/повторы → RF-проблема.
• Измените канал и ширину (2.4ГГц: 20 МГц, каналы 1/6/11). Используйте Wi‑Fi Analyzer на смартфоне, чтобы найти свободный канал.
• Для игровых сессий предпочтительнее 5 ГГц (меньше помех).
• Попробуйте временно отключить mesh/репитеры и подключиться к основному AP.

Ethernet

• Замените патч‑корд на известный рабочий кабель (CAT5e/6). Проверьте коннекторы.
• Проверьте скорость и дуплекс: ethtool eth0 (Linux) или свойства адаптера в Windows. Если auto‑negotiation даёт 100‑FD на одном конце и 1G‑HD на другом — будут потери.
• Отключите offload (LSO, GRO) в свойствах NIC при подозрении на проблемный драйвер.

Причины помех и физики описаны в обзоре Azone‑IT: https://www.azone-it.ru/articles-poterya-paketov

Как читать трассировку и где локализовать потери

MTR/WinMTR показывает процент потерь на каждом хопе. Важные правила интерпретации:

• Потери на первом хопе (ваш шлюз) — локальная проблема: NIC, кабель, роутер, коммутатор.
• Потери на первом хопе и ниже — вероятно локальный узел.
• Потери в промежуточном роутере, но отсутствующие на более дальних хопах — часто ICMP‑rate‑limit (маршрутизатор не отвечает на ICMP), это не обязательно значит, что реальный трафик теряется. Смотрите на потерю до конечной цели (последний hop).
• Постоянная потеря, которая начинается на одном хопе и сохраняется до конца маршрута — честный индикатор узла с проблемной маршрутизацией/сопряжением (провайдер/последний‑mile оборудование).

Если вы видите, что потери начинаются на вашем локальном IP/порт — меняйте кабель/порт/карту и повторяйте. Если потери начинаются на «следующем» за вашим роутером хопе и у соседей то же самое — соберите параллельные mtr от соседа и приложите к провайдеру.

Частые аппаратные и конфигурационные причины и их устранение

Кратко по причинам и быстрым решениям:

• Повреждённый патч‑корд / плохой разъём RJ‑45 → заменить.
• Плохой порт на коммутаторе / роутере → переподключить в другой порт, заменить коммутатор.
• Дуплекс/скорость mismatch → зафиксировать одинаковые параметры (обычно 1G full).
• Ошибки NIC/драйверов → обновить драйверы, отключить offload‑опции.
• Перегруженный роутер (CPU/NAT table) → отключить тяжёлые сервисы, временно заменить на более мощный/включить аппаратный NAT.
• PLC/мосты/гибридные мосты → отключить, проверить.
• Плохая подъездная линия/физический коннектор у столба → вызвать проверку провайдера; если соседям тоже плохо — это приоритет.
• Bufferbloat/плохая очередь при загрузках → включить SQM/fq_codel или ограничить upload, чтобы не заполнять буферы и не вызывать потери в играх.

Если нужна конфигурация SQM/ cake — это эффективно против потерь под нагрузкой; для роутеров с OpenWrt/LEDE — включите соответствующий пакет.

Сбор доказательств и взаимодействие с провайдером/соседями

Чем больше фактов — тем выше шанс добиться выезда техника.

1. Сделайте 2–3 mtr/WinMTR длительностью 5–10 минут к публичному IP (8.8.8.8, 1.1.1.1) и сохраните файлы.
2. Соберите ping‑логи: ping -n 500 8.8.8.8 > pinglog.txt (Windows) или ping -c 500 8.8.8.8 > pinglog.txt (Linux).
3. Снимите интерфейс‑логи: Get-NetAdapterStatistics, ethtool -S, скриншоты ошибок на роутере (syslog).
4. Снимите pcap (tcpdump/pktmon) на время проявления проблемы.
5. Координируйтесь с соседями: попросите их параллельно запустить mtr в те же временные окна — это докажет распределённый характер.

Пример короткого письма/запроса в техподдержку провайдера: опишите время, приложите mtr/pcap/ping, укажите, что потеря начинается на вашем участке (первый hop) и затрагивает соседей — требуйте полевого замера линнии/замены коннектора/проверки распределительного узла.

Если провайдер отказывается, настаивайте на выезде техника с прибором для измерения уровня сигнала/SNR/BER (для DSL/Cable/Fiber соответствующие метрики).

Практический чек‑лист по приоритетным действиям

Быстрое действие (0–30 мин)

• Перезагрузите модем и роутер, подключитесь напрямую к модему, повторите ping/mtr.
• Замените патч‑корд на прямой короткий cable.
• Отключите все PowerLine/mesh/дополнительные свитчи — оставьте только один компьютер и модем.

Диагностика (30–180 мин)

• Соберите mtr/WinMTR 10 минут, сохраните.
• Запустите iperf3 между двумя LAN‑хостами.
• Соберите pktmon/netsh/tcpdump capture.

Продвинутые (несколько часов/дней)

• Проверьте и обновите драйвера NIC и прошивку роутера.
• Измерьте и/или попросите провайдера проверить физическую линию.
• Если проблема связана с bufferbloat — включите SQM/ fq_codel.

Эскалация

• Приложите mtr/ping/pcap и попросите выезд техники с измерительными приборами.
• Координируйтесь с соседями для подтверждения массового инцидента.

Источники

1. Диагностика потери пакетов — Microsoft Learn
2. Потеря пакетов в сетях: диагностика, причины и решения — Pandora FMS
3. ПОТЕРЯ ПАКЕТОВ: Что такое потеря пакетов и как это исправить? — ExitLag
4. Потеря пакетов — Azone‑IT
5. Оптимизация соединения: снижение задержки и потери пакетов — Bungie Help
6. Устранение неполадок потери пакетов на сайте Socket — CatoNetworks Support
7. Как проверить потерю пакетов интернета — Simstar
8. Как исправить потерю пакетов — IP‑Calculator

Заключение

Потери пакетов в домашней сети надо лечить по этапам: подтвердить наличие на нескольких устройствах, изолировать локальную сеть (подключение напрямую к модему), собрать длительные трассировки (mtr/WinMTR), интерфейсные счётчики и pcap‑захват, затем по результатам — менять кабель/порт/коммутатор или требовать от провайдера проверки физической линии/районного узла. Если хотите, могу помочь: подскажите вывод mtr/WinMTR и результаты команд (Get‑NetAdapterStatistics / ethtool / tcpdump), и я подскажу следующий точный шаг.