Как проверить IP-адреса и маршрут сервера, не меняя сеть

Сервер не может обратиться к внешнему сервису, хотя сеть «вроде настроена». Первым делом стоит узнать фактические адреса и маршрут. Менять шлюз или перезапускать сетевую службу через удалённое подключение до этого опасно: можно потерять доступ и усложнить восстановление.

Инструкция рассчитана на Linux с iproute2. Команды ниже просматривают состояние и не заменяют сетевую конфигурацию.

Краткий вывод позволяет увидеть имена интерфейсов, состояние и назначенные адреса. Сравните их с ожидаемой схемой: публичная сеть, внутренняя сеть, VPN или контейнерные интерфейсы. Само наличие адреса не подтверждает доступность нужного получателя.

Проверяйте семейство адресов отдельно. Приложение может пытаться использовать IPv6, тогда как вручную вы смотрите только на рабочее соединение IPv4. Такие проверки нельзя считать эквивалентными.

Для обычных маршрутов IPv4 и IPv6:

Обратите внимание на маршрут по умолчанию, интерфейс и шлюз. Если используется маршрутизация по правилам, одной основной таблицы может быть недостаточно. Просмотр правил помогает понять, требуется ли дальнейшая проверка дополнительных таблиц:

Не удаляйте «лишние» маршруты по внешнему виду. Они могут обслуживать VPN, отдельного провайдера или служебный трафик, которого не видно в текущем пользовательском сценарии.

Введите IP-адрес получателя, который вы действительно проверяете, после команды чтения:

Это локальный поиск маршрута, а не отправка пробного запроса получателю. Он помогает увидеть выбранный интерфейс и исходный адрес. Успешный вывод не доказывает, что удалённая сторона отвечает или что firewall разрешает соединение.

Пример: запрос должен идти по внутренней сети, но выбран внешний маршрут. Нужно проверить адрес назначения, правила маршрутизации и схему VPN. Другой случай: путь выглядит правильным, но соединение не устанавливается. Тогда следующая проверка относится к доступности порта и правилам фильтрации, а не к случайной замене шлюза.

Если проблема появляется только у приложения, сравните его окружение с терминалом. Контейнер, отдельное сетевое пространство, прокси и политика маршрутизации могут менять путь. Успешный запрос с хоста не является полной проверкой контейнера.

Нужны время, IP получателя, семейство адресов, выбранный исходный адрес и интерфейс. Внешнему получателю передавайте только сведения, необходимые для поддержки: внутреннюю адресную схему не нужно публиковать целиком.

После согласованного изменения повторите тот же поиск маршрута и запрос к сервису. Если путь не изменился, а доступ восстановился, причина могла находиться на другом уровне. Итог диагностики должен объяснять, где именно нарушается связь, а не просто фиксировать очередной перезапуск сети.

В отчёт добавьте, выполнялась ли команда на хосте или внутри контейнера. Без этой детали два корректных вывода могут выглядеть противоречивыми.

The server cannot reach an external service even though the network appears configured. First, check the actual addresses and route. Changing the gateway or restarting the network service via a remote connection before this is dangerous: you may lose access and complicate recovery.

This guide is for Linux with iproute2. The commands below display status and do not alter network configuration.

A brief output shows interface names, status, and assigned addresses. Compare them with the expected layout: public network, internal network, VPN, or container interfaces. The mere presence of an address does not confirm reachability to the intended recipient.

Check address families separately. An application may attempt to use IPv6 while you manually inspect only the working IPv4 connection. Such checks cannot be considered equivalent.

For standard IPv4 and IPv6 routes:

Pay attention to the default route, interface, and gateway. If policy-based routing is in use, a single main table may be insufficient. Reviewing rules helps determine whether further inspection of additional tables is required:

Do not delete "extra" routes based on appearance. They may serve VPNs, a separate provider, or background traffic not visible in the current user scenario.

Enter the destination IP address you are actually verifying after the read command:

This is a local route lookup, not a probe sent to the destination. It helps reveal the selected interface and source address. A successful output does not prove that the remote side responds or that the firewall allows the connection.

Example: the request should go through the internal network, but an external route was selected. Check the destination address, routing rules, and the VPN scheme. Another case: the path looks correct, but the connection fails. In that scenario, the next check concerns port availability and filtering rules, not a random gateway replacement.

If the issue occurs only in the application, compare its environment with the terminal. A container, a separate network namespace, a proxy, or a routing policy can alter the path. A successful request from the host is not a complete verification of the container.

You need the timestamp, recipient IP, address family, selected source address, and interface. For external recipients, transmit only the information necessary for support; do not publish the entire internal addressing scheme.

After a confirmed change, repeat the same route search and service request. If the path has not changed but access is restored, the cause may lie at another level. The diagnostic conclusion must explain exactly where the connection breaks, not merely record another network restart.

In the report, specify whether the command was executed on the host or inside the container. Without this detail, two correct findings may appear contradictory.