Learning Platform
Глоссарий
Troubleshooting

Troubleshooting — Computer Networks для Junior

База знаний типичных ошибок курса Computer Networks для Junior.

Категория

Показано 27 из 27 ошибок

Симптомы

  • Браузер не открывает страницы, любые сетевые запросы фейлятся. Может быть полностью (никакие хосты не доступны) или частично (некоторые сайты работают).

Причина

L1: кабель не подключён, Wi-Fi не сконнектился, физическая поломка адаптера L2: проблема с DHCP -- не получили IP-адрес (видно как 169.254.x.x на Linux/macOS или 0.0.0.0) L3: получили IP, но нет связи с gateway (ping gateway не идёт) L3 routing: есть связь с gateway, но он не пускает дальше (роут до 8.8.8.8 ломается) L4-7: gateway пускает, но DNS не резолвит (ping 8.8.8.8 ок, ping google.com нет) Captive portal в публичном Wi-Fi -- надо открыть browser и пройти auth

Решение

  1. L1: переподключить кабель, перезайти в Wi-Fi, проверить адаптер sudo ip link set en0 up
  2. L2: запросить новый IP через DHCP -- sudo dhclient -v eth0 (Linux), sudo ipconfig set en0 DHCP (macOS)
  3. L3 нет gateway: проверить роуты ip route, добавить default gateway sudo ip route add default via 192.168.1.1
  4. L3 gateway не отвечает: рестарт router'а, проверить кабели, ARP-таблицу ip neigh
  5. DNS: попробовать другой resolver -- sudo systemd-resolve --set-dns=8.8.8.8 --interface=eth0 или через /etc/resolv.conf
  6. Captive portal: открыть neverssl.com или 1.1.1.1 в браузере -- должен показать страницу авторизации

Симптомы

  • curl/browser ругаются: 'Could not resolve host: example.com', 'name or service not known', 'NXDOMAIN'. Ping по IP работает, по имени нет.

Причина

Системный resolver сломан или недоступен (/etc/resolv.conf пуст или указывает на dead resolver) DNS-сервер провайдера перегружен или фильтрует домен Домен реально не существует (опечатка, истёк, не зарегистрирован) Локальное переопределение в /etc/hosts указывает на неверный IP DNSSEC validation failure -- запись подписана неверно, валидирующий resolver отказывает VPN изменил resolver, но не пробрасывает запросы корректно Корпоративный DNS блокирует внешние домены или требует VPN

Решение

  1. Сменить resolver на публичный: добавить nameserver 8.8.8.8 в /etc/resolv.conf (Linux без systemd-resolved)
  2. Через systemd-resolved: sudo resolvectl dns eth0 8.8.8.8 1.1.1.1
  3. macOS: System Settings > Network > Wi-Fi > Details > DNS -- добавить 1.1.1.1
  4. Очистить локальный DNS-кэш: sudo killall -HUP mDNSResponder (macOS), sudo systemd-resolve --flush-caches (Linux)
  5. Если домен не существует -- проверить регистрацию через whois example.com
  6. Если DNSSEC fail -- попробовать resolver без DNSSEC валидации, репортить владельцу зоны
  7. При VPN -- проверить, что VPN client настраивает DNS правильно (split-DNS если нужно)

Симптомы

  • Каждое первое открытие сайта занимает 1-2 секунды на резолв, потом быстро. dig example.com показывает Query time: 300 ms.

Причина

DNS-сервер далеко (географически) или перегружен Системный resolver идёт каскадом через несколько узлов (Pi-hole -> upstream -> ...) DNS over HTTPS / DNS over TLS добавляет latency на handshake Local DNS cache (nscd / systemd-resolved) сломан или отключён ISP делает DNS hijacking -- перенаправляет на свой slow resolver Domain имеет очень короткий TTL (5 сек) -- кэш не работает, каждый раз идём заново Загруженный uplink -- DNS-пакет ждёт в очереди

Решение

  1. Переключиться на быстрый resolver: 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), 9.9.9.9 (Quad9)
  2. Включить локальный DNS-кэш: systemd-resolved (Linux), dnsmasq, или Unbound в caching mode
  3. Использовать DoH через Cloudflare WARP / NextDNS -- иногда быстрее plain DNS
  4. Если ISP делает DNS hijacking -- VPN или DoH спасают
  5. При очень коротких TTL -- ничего не сделаешь, владелец домена так настроил (часто для health checks)
  6. Проверить нагрузку на uplink: запустить speedtest во время медленного DNS

Симптомы

  • curl: 'SSL: error:1408F10B' или 'SSL routines:ssl3_get_record:wrong version number'. Browser: 'SSL_PROTOCOL_ERROR', 'ERR_SSL_VERSION_OR_CIPHER_MISMATCH'.

Причина

Несовместимые версии TLS -- клиент TLS 1.3, сервер только TLS 1.0/1.1 Нет общих cipher suites между клиентом и сервером Сертификат сервера expired -- браузер отказывается продолжать Сертификат подписан неизвестным CA (self-signed или корпоративный CA) Hostname mismatch -- сертификат на другой домен (SAN не совпадает) SNI не настроен -- сервер отдаёт default cert вместо нужного MITM proxy в инспектирующем режиме режет TLS

Решение

  1. Если сервер на старом TLS -- попросить admin обновить (TLS 1.0/1.1 deprecated с 2020)
  2. Обновить клиента: brew upgrade openssl, обновить Python/curl
  3. Сертификат expired -- ops чинит на сервере (Let's Encrypt auto-renew)
  4. Self-signed: добавить сертификат в trust store, или curl --cacert /path/to/ca.pem
  5. Hostname mismatch: использовать правильный hostname или --resolve override
  6. Проверить, что используется SNI: openssl s_client требует -servername

Симптомы

  • Connection refused: сервер ответил мгновенно отказом (TCP RST). Connection timed out: сервер не отвечает вообще, клиент висит 30-120 секунд.

Причина

Refused: на сервере никто не слушает на этом порту, ядро шлёт TCP RST в ответ на SYN Refused: SELinux / AppArmor блокирует bind Timeout: пакет дошёл до фильтра, который тихо дропает (DROP в iptables, default в security groups) Timeout: маршрут до сервера сломан, пакет потерян по пути Timeout: сервер перегружен и не успевает accept Timeout: VPN не пропускает, или firewall в политике DROP (не REJECT)

Решение

  1. Refused: убедиться, что приложение запущено и слушает на правильном порту/интерфейсе (0.0.0.0 vs 127.0.0.1)
  2. Refused от 127.0.0.1: приложение биндится только на localhost -- надо bind на 0.0.0.0 для внешнего доступа
  3. Timeout с firewall: проверить iptables -L (Linux), security groups (AWS), Windows Firewall
  4. Timeout без firewall: traceroute -T -p 443 example.com -- где обрывается
  5. Timeout из-за routing: проверить ip route, BGP-announcements у провайдера
  6. Если timeout из конкретной локации -- может быть geo-blocking; VPN из другой страны проверит

Симптомы

  • При старте сервера: 'OSError: [Errno 98] Address already in use', 'EADDRINUSE: address already in use 0.0.0.0:8080'. Сервер не стартует.

Причина

Другой процесс уже слушает на этом порту Предыдущий запуск этого же сервера не завершился (висит как zombie) Соединение в состоянии TIME_WAIT держит порт (после crash или kill без graceful shutdown) Порт зарезервирован системой как ephemeral (если ниже /proc/sys/net/ipv4/ip_local_port_range) Bind на 0.0.0.0:8080 конфликтует с bind на 127.0.0.1:8080

Решение

  1. Найти и убить процесс: kill <PID> (graceful), kill -9 <PID> (force)
  2. Если TIME_WAIT: подождать ~60 секунд, или включить SO_REUSEADDR в коде сервера (Python: server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1))
  3. Сменить порт на свободный (8081, 8082, ...) -- временный workaround
  4. При Docker: docker ps -- может быть запущен контейнер с -p 8080:8080
  5. При macOS Sonoma+: AirPlay Receiver использует port 5000, отключить в System Settings
  6. Долгосрочно: в production добавить SO_REUSEADDR в socket setup

Симптомы

  • ping до 8.8.8.8 = 10ms, ping до api.example.com = 500ms. Только до одного сервиса медленно, остальные ок.

Причина

Сервер физически далеко (другой континент) Маршрут через перегруженный или плохой ISP -- traceroute покажет, где скачок BGP-маршрут не оптимален: пакет идёт через далёкий transit Сервер перегружен -- ICMP обрабатывается с задержкой (хотя ICMP должен быть приоритетным) CDN edge для вашего региона не работает, fallback на origin Локальный uplink перегружен -- bufferbloat QoS на промежуточном узле дропает или замедляет ICMP/UDP

Решение

  1. Если latency = расстояние -- ничего не сделаешь без VPN или edge ближе
  2. Если плохой hop -- репортить ISP, использовать другого provider
  3. Если CDN edge не работает -- очистить DNS-кэш, попробовать другой resolver (geoDNS даст ближайший)
  4. Bufferbloat: настроить SQM (Smart Queue Management) на router'е (CAKE, fq_codel)
  5. Использовать CDN с anycast (Cloudflare, Fastly) -- меньше зависит от маршрутов
  6. Для критичных сервисов: дедикейтед канал (AWS Direct Connect, GCP Interconnect)

Симптомы

  • ping показывает X% packet loss. TCP-сессии страдают (медленно, иногда RST). Видео-звонки лагают.

Причина

Плохое физическое соединение (старый кабель, помехи на Wi-Fi) Перегруженный uplink -- роутер дропает пакеты, не успевая отправить Дефектный hop по маршруту -- mtr покажет на каком MTU mismatch + ICMP заблокирован -- большие пакеты дропаются молча Wi-Fi rate adaptation -- слабый сигнал = больше retransmits = выглядит как loss Сервер дропает: bufferbloat, rate limiting, DDoS-фильтр Half-duplex mismatch (раритет, но бывает на старых свичах)

Решение

  1. Wi-Fi: переключиться на 5 GHz или ближе к точке доступа, поменять канал
  2. Ethernet: проверить кабель (тестер или просто заменить), порты на свиче
  3. Bufferbloat на uplink: SQM на router'е
  4. MTU: попробовать ping -M do -s 1472 example.com (MTU 1500 - 28 = 1472); если фейлит, ОС или маршрут роняют MTU
  5. Если loss только в одной AS -- репортить ISP
  6. Большие потери на сервере: смотреть в логи rate limiting, DDoS-защиту

Симптомы

  • Странные SSL-warning'и (cert не от того CA), трафик идёт через неизвестный gateway, дублирующиеся MAC-адреса в ARP-таблице, MITM-detection алерт.

Причина

Атакующий шлёт gratuitous ARP, ассоциируя свой MAC с IP gateway Атакующий шлёт ARP-ответы 'IP жертвы = мой MAC', перехватывая обратный трафик Неисправный сетевой адаптер шлёт мусорные ARP Дубликат IP в сети -- два хоста считают, что IP их Тест от security team / red team Mobile device с broken NetworkManager в hotspot mode

Решение

  1. Сразу: отключиться от untrusted Wi-Fi, перейти на VPN или mobile data
  2. Long-term defense: статические ARP-записи для gateway -- ip neigh add 192.168.1.1 lladdr aa:bb:cc:dd:ee:ff dev eth0
  3. На enterprise switch: включить DAI (Dynamic ARP Inspection) и DHCP snooping
  4. Использовать VPN с end-to-end шифрованием -- даже при ARP poisoning контент защищён TLS
  5. Запустить arpwatch для долгосрочного мониторинга изменений
  6. В корпоративной сети репортить security team -- может быть инсайдер или взломанный host

Симптомы

  • После подключения к сети нет IP-адреса, или получили link-local 169.254.0.0/16 (APIPA). ip addr show показывает inet 169.254.x.x.

Причина

DHCP-сервер недоступен или не отвечает (broadcast не дошёл) DHCP-сервер исчерпал pool адресов MAC-filtering на DHCP-сервере -- ваш MAC не в whitelist Wi-Fi подключился к сети, но без auth/captive portal Сетевой адаптер сломан или драйвер криво загрузился Слишком жёсткий timeout DHCP-клиента (особенно при гибридных Wi-Fi) VLAN mismatch -- порт настроен на untagged VLAN, в котором нет DHCP

Решение

  1. Force renewal: sudo dhclient -v eth0 или sudo ipconfig set en0 DHCP
  2. Перезагрузить сетевой стек: sudo systemctl restart NetworkManager (Linux), wifi off/on (macOS)
  3. Wi-Fi: отключиться, забыть сеть, переподключиться (часто из-за protected/auth state)
  4. Если есть admin доступ к router: проверить DHCP pool, освободить leases
  5. Временный workaround: ручной static IP в той же подсети -- но только если знаете свободный
  6. MAC filtering: добавить MAC в whitelist или сменить MAC: sudo ip link set eth0 address aa:bb:cc:dd:ee:ff

Симптомы

  • example.com не открывается, google.com и yandex.ru работают. Curl или browser виснут или возвращают timeout/refused.

Причина

Сайт реально лежит (down, проверь downforeveryoneorjustme.com) DNS-резолв даёт неверный IP -- DNS cache, /etc/hosts override, geo-routing fail ISP блокирует сайт по требованию регулятора Cloudflare/CDN считает вас ботом (после VPN или massive requests) -- 1020 Access Denied Firewall на вашей стороне блокирует destination IP/range Сайт переехал на новый IP, у вас старая DNS-запись BGP-проблема -- маршрут до AS сайта обрывается

Решение

  1. DNS cache: sudo killall -HUP mDNSResponder (macOS), sudo resolvectl flush-caches (Linux)
  2. Сменить resolver: dig @8.8.8.8 example.com -- если резолвится, проблема в resolver'е
  3. Если IP отдаёт правильный, но не reachable -- проверить firewall: iptables -L (Linux), sudo pfctl -s rules (macOS)
  4. ISP block: VPN из другой страны проверит -- если работает, это блокировка
  5. Cloudflare 1020: подождать, очистить cookies, отключить VPN -- через 24 часа разблочат
  6. Если сайт down -- ждать, репортить владельцам, проверять @site_status в Twitter

Симптомы

  • Сервер отвечает 502 Bad Gateway или 504 Gateway Timeout. NGINX/HAProxy/CloudFront показывает свою error page.

Причина

502: backend ответил невалидным HTTP, или соединение оборвалось (TCP RST / FIN до ответа) 502: backend crash во время обработки запроса 504: backend не успел ответить за configured timeout (например, NGINX proxy_read_timeout = 60s) 504: backend overloaded -- очередь запросов, не успевает Long-running query в БД -- backend ждёт DB, proxy ждёт backend, всё timeout Связь между proxy и backend сломана -- VPC routing, security group, network split TLS между proxy и backend -- если backend требует HTTPS, а proxy шлёт plain

Решение

  1. 502: чинить backend -- crash, segfault, restart
  2. 504: увеличить timeout на proxy (NGINX proxy_read_timeout, ALB idle_timeout) ИЛИ оптимизировать backend
  3. Long DB query: оптимизировать запрос, добавить индексы, async-обработка с polling
  4. Backend overload: горизонтально масштабироваться (больше pods/instances), включить autoscaling
  5. Network split: проверить, что backend reachable с proxy -- curl с proxy-машины
  6. TLS mismatch: настроить proxy_pass на правильную схему (http:// vs https://)
  7. Если 502/504 нестабильно -- circuit breaker на proxy и retry с jitter

Симптомы

  • Browser console: 'Access to fetch at https://api.example.com/data from origin https://app.example.com has been blocked by CORS policy: No Access-Control-Allow-Origin header'. Запрос в Network видим, ответ 200 -- но JS не может прочитать.

Причина

Сервер не возвращает Access-Control-Allow-Origin или возвращает другой origin Preflight (OPTIONS) запрос не возвращает корректные headers (Access-Control-Allow-Methods, Headers) Используется credentials (cookies) -- сервер не вернул Access-Control-Allow-Credentials: true Wildcard Allow-Origin: * не сочетается с credentials -- надо точный origin В CORS-headers неверный case или typo Proxy/CDN срезает CORS-headers по пути Production-only баг: на dev origin localhost:3000 в whitelist, production app.com нет

Решение

  1. Сервер: добавить header Access-Control-Allow-Origin: https://app.example.com (точный или валидный domain)
  2. Сервер: обработать OPTIONS preflight -- вернуть 204 с Access-Control-Allow-Methods и Headers
  3. С cookies: Access-Control-Allow-Origin не может быть *; нужен точный origin + Allow-Credentials: true; и withCredentials: true в fetch
  4. Если домены разные (api.example.com и app.example.com) -- настроить CORS-policy explicitly
  5. Workaround на dev: запустить browser с --disable-web-security (только для дебага)
  6. Лучше -- использовать reverse proxy: app.example.com/api/* -> api.example.com -- same origin, CORS не нужен

Симптомы

  • Curl: 'curl: (56) Recv failure: Connection reset by peer'. Приложение: 'ECONNRESET'. Запрос идёт, потом обрывается.

Причина

Сервер послал TCP RST -- например, после crash, kill -9, или явного reset(2) Firewall в середине пути послал RST для разрыва сессии (stateful inspection) Сервер закрыл соединение по timeout, но клиент пытался писать -- получил RST Idle timeout на load balancer (NGINX upstream_keepalive_timeout, AWS ALB idle_timeout по умолчанию 60s) OOM killer убил backend-процесс MTU mismatch с PMTUD не работает -- packet drop, потом timeout, потом RST Application layer: сервер обнаружил malformed запрос и сбросил соединение

Решение

  1. Если RST после длительного idle -- настроить TCP keep-alive: net.ipv4.tcp_keepalive_time = 60
  2. На LB: увеличить idle_timeout, или клиент должен слать keep-alive часто
  3. OOM: добавить memory limits в systemd unit или Kubernetes, увеличить swap
  4. Сервер crash: чинить root cause -- логи, sentry, ASAN
  5. Stateful firewall: проверить session table; иногда нужно увеличить timeout
  6. Application-level: ловить ECONNRESET, retry с backoff (для idempotent запросов)

Симптомы

  • На одном интерфейсе интернет, на другом нет. Часто после смены кабеля, реконфигурации, апдейта macOS/Linux.

Причина

Метрики routes: оба интерфейса имеют default gateway, но с разным приоритетом -- система использует один Один интерфейс получил IP, другой нет (DHCP fail) DNS-серверы прописались только на одном интерфейсе Кабель Ethernet сдох, или порт на свиче деактивирован macOS Service Order не пускает Ethernet (System Settings > Network > ... > Set Service Order) VLAN tagging требуется на Ethernet, на Wi-Fi нет VPN -- только один интерфейс в split tunneling

Решение

  1. Linux: настроить metric для routes -- меньше metric = выше приоритет; sudo ip route change default via 192.168.1.1 dev eth0 metric 100
  2. macOS: System Settings > Network > ... > выбрать интерфейс > Set Service Order сверху вниз по приоритету
  3. Force использовать интерфейс: sudo route delete default; sudo route add default 192.168.1.1 -ifscope en0
  4. Ethernet порт мёртв -- физически проверить link LED, ethtool eth0 покажет 'Link detected: yes/no'
  5. VLAN: настроить VLAN-интерфейс на Ethernet (vconfig add eth0 100)
  6. На время дебага можно отключить ненужный интерфейс: sudo ip link set wlan0 down

Симптомы

  • VPN client показывает Connected. Public интернет работает. Но internal-сервисы (10.0.0.0/8 диапазон) недоступны. Или наоборот: internal ок, наружу нет.

Причина

Split tunneling: VPN роутит только internal, остальное напрямую (или наоборот) Маршрут до internal-подсети не добавлен в routing table после VPN-up DNS не пробрасывается через VPN -- internal-имена не резолвятся Конфликт IP-диапазона: ваша local-сеть 10.0.0.0/24, internal тоже 10.0.0.0/24 -- маршруты ломаются Firewall на стороне корпоративной сети не пускает ваш source IP (assigned VPN client IP) MTU слишком большой -- internal-сервис не отвечает на большие пакеты

Решение

  1. Добавить маршрут вручную: sudo ip route add 10.0.0.0/8 dev tun0
  2. DNS: добавить internal-resolver в /etc/resolv.conf или systemd-resolved override
  3. Конфликт IP: сменить local subnet (192.168.42.0/24 вместо 10.x); или корпорация даёт другой client IP range
  4. Split tunneling: проверить настройки VPN client -- 'Send all traffic over VPN' или 'Only specific subnets'
  5. MTU: настроить tun-interface на меньший MTU (1400 типично): sudo ip link set dev tun0 mtu 1400
  6. Если firewall блочит: запросить ops -- какой source IP whitelist'ить, обычно VPN client pool

Симптомы

  • После включения DoH в браузере или системе -- часть сайтов не открывается, internal-домены не резолвятся, медленно работает.

Причина

DoH идёт мимо корпоративного split-DNS -- internal-домены не резолвятся DoH-провайдер блокирует домены (Quad9 фильтрует malware -- может зацепить и false positive) Корпоративный firewall блокирует подключение к DoH-серверам DoH-сервер медленный или недоступен -- timeout каждого запроса Browser использует DoH, ОС нет -- разнобой между ними DoH не следует /etc/hosts override

Решение

  1. Для internal-доменов настроить split-DoH: корпоративные домены через internal resolver, остальное -- DoH
  2. Browser: в Firefox network.trr.excluded-domains -- список доменов, для которых не использовать DoH
  3. Сменить DoH-провайдера: Cloudflare, Google, Quad9, NextDNS -- разная фильтрация
  4. Корпоративная сеть может вообще запрещать DoH -- использовать system DNS как обычно
  5. Если медленно -- использовать DNSCrypt, или вернуться к plain DNS
  6. Проверить, что у ОС и browser один и тот же resolver -- избегать рассогласования

Симптомы

  • Некоторые сайты работают медленно или не работают совсем (только IPv6, fallback на v4 не успевает). Некоторые приложения timeout на резолве AAAA.

Причина

ISP даёт IPv6, но маршрутизация в часть интернета сломана (broken IPv6) Браузер сначала пробует IPv6 (Happy Eyeballs), timeout -- потом IPv4 -- видим как delay DNS возвращает AAAA, но v6 не работает -- timeout, fallback на A Local firewall блокирует IPv6 outbound по умолчанию VPN не поддерживает IPv6 -- утечка через v6 в обход VPN, либо v6 полностью off MTU mismatch: IPv6 не фрагментирует на роутерах, нужен PMTUD router'у не настроены RA (Router Advertisement)

Решение

  1. Если v6 broken: отключить на интерфейсе: sudo sysctl net.ipv6.conf.eth0.disable_ipv6=1
  2. Force IPv4 в приложениях: в Python socket.AF_INET, в curl -4
  3. Включить Happy Eyeballs v2 (RFC 8305) -- быстрее fallback, < 250ms timeout
  4. MTU: настроить меньший MTU на роутере (1280 -- минимум для IPv6)
  5. VPN: убедиться, что v6 либо полностью off, либо tunneled (иначе утечка реального IPv6 -- privacy leak)
  6. Проверять провайдера: репортить broken v6, попросить native IPv6 или 6rd tunnel

Симптомы

  • Маленькие запросы (ping, простой GET) работают. Большие (POST с body, скачивание файла) виснут или timeout. Часто на VPN, GRE, IPsec.

Причина

Туннель добавляет overhead (IPsec ~50 байт, GRE ~24, WireGuard ~60), эффективный MTU меньше 1500 Промежуточный роутер режет пакет, но ICMP 'Fragmentation Needed' блокирован firewall'ом DF (Don't Fragment) bit стоит, фрагментация запрещена -- пакет дропается молча В IPv6 фрагментация только на отправителе -- если PMTUD сломан, обрыв TCP MSS Clamping не настроен на роутере -- большие сегменты не режутся под MTU

Решение

  1. Установить меньший MTU на интерфейсе: sudo ip link set dev tun0 mtu 1380
  2. Включить TCP MSS clamping на роутере: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
  3. Разрешить ICMP Fragmentation Needed (type 3 code 4) в firewall'е -- никогда не блочить
  4. Для WireGuard: установить MTU 1380 (или 1280 для conservative)
  5. Если ничего не помогает -- отключить DF bit (но это плохо для производительности)
  6. Сначала чинить ICMP -- PMTUD должен работать; меньший MTU -- workaround

Симптомы

  • В Wireshark или tcpdump видно много '[TCP Retransmission]', '[TCP Dup ACK]'. Throughput низкий несмотря на хороший link.

Причина

Реальные потери пакетов -- сетевая проблема, см. packet-loss Out-of-order delivery -- асимметричный routing, разные пути для пакетов Receiver окно нулевое -- получатель медленно читает (backpressure) Spurious retransmissions: ACK задержался, отправитель решил, что потеря, повторил Wi-Fi: retransmits на L2 не видны TCP, но increase RTT, заставляют RTO срабатывать Bad NIC driver: дропает пакеты при заполнении ring buffer TSO/GSO/GRO offloading сломан -- крупные сегменты теряются, ретрансмит мелкими

Решение

  1. Чинить root cause loss -- кабель, Wi-Fi сигнал, перегруженный hop
  2. Disable TSO/GSO/GRO для теста: sudo ethtool -K eth0 tso off gso off gro off
  3. На сервере при backpressure: увеличить receive buffer; в приложении быстрее читать из socket
  4. Сменить congestion control algorithm: sudo sysctl net.ipv4.tcp_congestion_control=bbr (вместо cubic)
  5. Увеличить TCP buffers: net.core.rmem_max, net.ipv4.tcp_rmem
  6. Если spurious -- настроить RTO min/max, включить F-RTO (RFC 5682)

Симптомы

  • Wireshark запускается, но в списке интерфейсов пусто. Или интерфейсы есть, но при capture показывает 0 packets. На Linux/macOS.

Причина

Wireshark запущен без root / прав на capture (нет CAP_NET_RAW) На Linux не настроен setuid на dumpcap, или не в группе wireshark macOS: ChmodBPF не установлен (ставится при инсталляции Wireshark, но иногда сбрасывается) Capture фильтр слишком жёсткий и режет всё Promiscuous mode не работает (не у каждого NIC можно включить) Запись с loopback на macOS требует специального BPF На Wi-Fi видны только свои пакеты в managed mode -- для монитора нужен monitor mode

Решение

  1. Linux: добавить себя в группу wireshark: sudo usermod -aG wireshark $USER (нужен relogin)
  2. Linux: дать capabilities dumpcap: sudo setcap cap_net_raw,cap_net_admin+eip /usr/bin/dumpcap
  3. macOS: переустановить Wireshark с brew install --cask wireshark; запустить /Applications/Wireshark.app/Contents/Resources/Extras/Install\ ChmodBPF.pkg
  4. Удалить capture фильтр -- начать с пустого фильтра, потом сужать
  5. Wi-Fi monitor mode: на macOS airport sniff <channel>, на Linux iw dev wlan0 set type monitor
  6. Loopback на macOS: использовать интерфейс 'Loopback: lo0' если есть

Симптомы

  • traceroute example.com: первые 3-4 hop'а показывают IP, потом N звёздочек, потом снова IP последнего hop'а.

Причина

Промежуточный роутер не отвечает на ICMP Time Exceeded (отключено или rate-limit) Роутер отвечает, но ICMP заблокирован firewall'ом на обратном пути Routing асимметричен -- ответ идёт другим путём через другие роутеры MPLS-сегмент: роутеры внутри MPLS-cloud не дегенерируют TTL (или дегенерируют только в edges) Великий китайский firewall и подобные: дропают часть ICMP traceroute использует UDP/порт 33434+ -- может быть блокирован, попробуй -T или -I Антифрод-системы у крупных сервисов (Cloudflare) могут rate-limit ICMP

Решение

  1. Звёздочки сами по себе НЕ значат разрыв -- если последний hop достигнут, всё ок
  2. Если последний hop в звёздочках -- destination недостижим
  3. Попробовать -T (TCP) или -I (ICMP) вместо UDP
  4. Если по UDP-портам блочат, по TCP/443 обычно проходит лучше
  5. Если хочется точную картину -- mtr с большим количеством циклов даёт стабильную статистику
  6. Принять как есть: privacy/security соображения у админов часть hop'ов скрывают

Симптомы

  • ping/curl выдаёт 'Network is unreachable' или 'No route to host' или 'Destination Host Unreachable'.

Причина

'Network unreachable': в routing table нет маршрута до целевой подсети (даже default gateway не помогает) 'No route to host': есть маршрут, но gateway не знает, как добраться (ARP не разрешает) 'Host unreachable' от ICMP: роутер по пути не может доставить (нет маршрута дальше) Default gateway упал -- маршрут есть, но gateway не отвечает VPN отключился и удалил маршруты, остались только локальные Конфликт routes -- более специфичный (longer prefix) с неработающим next-hop

Решение

  1. 'Network unreachable' -- добавить default route: sudo ip route add default via 192.168.1.1
  2. 'No route to host' -- проверить ARP, очистить: sudo ip neigh flush all; перезапустить интерфейс
  3. Gateway упал -- рестарт роутера, проверить кабели
  4. VPN dropped routes -- переподключиться, или вручную добавить: sudo ip route add 10.0.0.0/8 dev tun0
  5. Конфликт routes -- удалить лишний: sudo ip route del 10.0.0.0/8 via <broken-gateway>
  6. Если ничего не помогает -- ip route show table all (видит маршруты в других таблицах), и rule list

Симптомы

  • curl: 'SSL certificate problem: self signed certificate'. Browser: 'NET::ERR_CERT_AUTHORITY_INVALID', 'Your connection is not private'. Python requests: 'SSLError: CERTIFICATE_VERIFY_FAILED'.

Причина

Сервер использует самоподписанный сертификат (typical для internal/staging) Сертификат подписан корпоративной CA, не входящей в системный trust store Истёкший сертификат сертификата (corner case -- CA expired) MITM-proxy в инспектирующем режиме подменяет cert Сертификат signed корректно, но trust chain broken (intermediate CA не отдаётся сервером)

Решение

  1. Добавить cert в системный trust store (Linux): sudo cp cert.pem /usr/local/share/ca-certificates/myca.crt && sudo update-ca-certificates
  2. macOS: sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain cert.pem
  3. Python -- использовать truststore (3.10+): pip install truststore && truststore.inject_into_ssl()
  4. Per-request override в curl: curl --cacert /path/to/ca.pem; в requests: verify='/path/to/ca.pem'
  5. Никогда в prod, только дебаг: curl -k или verify=False -- отключает защиту полностью
  6. Если broken chain -- ops чинит на сервере: настроить full chain (server cert + intermediate)

Симптомы

  • curl example.com висит, ничего не выводит, не таймаутит самостоятельно (или таймаутит через 120+ сек).

Причина

Сервер ответил, но не закрывает соединение -- ждёт ещё запроса (HTTP keep-alive) Connect ok, но сервер не отвечает на HTTP-запрос (overloaded, ждёт DB) Файрвол дропает пакеты тихо (DROP, не REJECT) Сервер -- streaming endpoint -- надо ждать или прервать вручную DNS-резолв висит (системный resolver сломан) На сервере backend получил запрос и ушёл в бесконечный loop

Решение

  1. Всегда ставить --connect-timeout и --max-time: curl --connect-timeout 10 --max-time 60 https://example.com
  2. Если streaming endpoint -- использовать -N (--no-buffer) и просто остановить через Ctrl+C
  3. DNS висит -- сменить resolver: curl --resolve example.com:443:1.2.3.4 https://example.com
  4. Если ждёт keep-alive -- HTTP 1.0 не использует: curl --http1.0 https://example.com
  5. При длинном backend processing -- увеличить max-time или async-обработка с polling
  6. Сравнить с другого host'а -- если там работает, проблема в локальной сети

Симптомы

  • Внезапно теряется сеть, потом восстанавливается. arp -an показывает несколько MAC за одним IP. ОС выводит 'duplicate IP detected'.

Причина

Два host'а получили один static IP DHCP-сервер выдал IP, который уже занят (static на другом host'е) DHCP-leases не синхронизированы между несколькими серверами Сетевой адаптер с broken DAD (Duplicate Address Detection) Network bridge неправильно настроен -- один IP виден через два пути ARP spoofing атака

Решение

  1. Сменить IP на одном из конфликтующих host'ов
  2. В DHCP-сервере: добавить IP в exclude-list, чтобы не выдавался
  3. Если несколько DHCP-серверов -- настроить failover/sharing pool, или оставить один
  4. На сетевом порту: limit MAC addresses (port security) -- предотвращает spoofing
  5. Включить arping -D в скрипте startup сервиса -- проверять перед bind
  6. Если ARP spoofing -- см. arp-poisoning-suspicion

Симптомы

  • Link 1 Gbps, но iperf3 показывает 50 Mbps. scp медленный. При этом ping ок, loss нет.

Причина

Маленькие TCP buffers -- BDP (bandwidth-delay product) больше window size Default congestion control (cubic) не оптимален для long-fat networks TCP window scaling не работает (старый сервер или мидл-боксы) Высокий latency без масштабирования окна -- 1 RTT cap на propagation Single-thread bottleneck -- TCP делит ресурсы между стримами; одиночный stream не насыщает Запросы маленькие -- много syscalls и context switches убивают throughput

Решение

  1. Включить BBR (вместо cubic): sudo sysctl net.ipv4.tcp_congestion_control=bbr
  2. Увеличить TCP buffers: net.ipv4.tcp_rmem = '4096 87380 16777216', net.core.rmem_max = 16777216
  3. Использовать параллельные стримы (-P в iperf3, --transfers в rsync)
  4. Включить TCP window scaling: sudo sysctl net.ipv4.tcp_window_scaling=1
  5. Если приложение -- batch syscalls (sendfile, splice, io_uring)
  6. Jumbo frames (MTU 9000) если все hop'ы поддерживают -- меньше overhead
Не нашли свою ошибку? Используйте Cmd+K (Ctrl+K) для поиска по тексту ошибки во всей базе знаний. Также обратитесь к урокам модулей для более глубокого понимания механизмов и диагностики проблем.