После обновления Proxmox сервер загрузился, но веб-интерфейс и SSH недоступны, а в консоли появляется Network is unreachable. Начните с проверки трёх вещей: видит ли система физический сетевой порт, подключён ли он к нужному мосту и существует ли маршрут до адреса назначения. По результатам станет понятно, нужно исправлять конфигурацию, разбираться с запуском служб или временно загружать предыдущее ядро.

Ниже — порядок восстановления через консоль узла. Примеры настройки относятся к обычной схеме с Linux Bridge. Если используются Open vSwitch, SDN, bond, отдельная сеть управления или маршрутизируемая подсеть провайдера, сохраняйте существующую схему: готовый пример с vmbr0 не заменяет её.

Как получить доступ, если не работают SSH и веб-интерфейс

Откройте независимую консоль сервера: IPMI, iKVM, консоль провайдера либо подключите монитор и клавиатуру. Нужна именно консоль хоста Proxmox. Консоль виртуальной машины и раздел Shell в недоступной панели задачу не решают.

Если независимого доступа нет, запросите его у провайдера. В обращении укажите, что после обновления и перезагрузки пропала сеть, и попросите предоставить консоль либо проверить состояние системы локально. Заказывать переустановку на этом этапе не требуется: диски виртуальных машин могут быть исправны, а причина — в одной сетевой настройке.

Команды далее выполняются от root на узле Proxmox, если отдельно не указано другое. Применять изменения сети следует с открытой независимой консолью: ошибка в порте, адресе или шлюзе может оборвать оставшийся удалённый доступ.

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

Определите, что именно перестало работать

Фраза «в Proxmox нет сети» объединяет несколько разных неисправностей. Выберите свой симптом, прежде чем менять настройки.

Обратите внимание, где появилась ошибка. Сообщение Network is unreachable внутри ВМ относится к её сетевому окружению. Аналогичная ошибка на вашем компьютере может означать проблему маршрута на компьютере, а не на сервере.

Сохраните настройки и снимите состояние сети

До редактирования создайте копию сетевой конфигурации:

PVE_NET_BACKUP="/root/pve-network-$(date +%Y%m%d-%H%M%S)"
cp -a /etc/network "$PVE_NET_BACKUP"
printf '%s\n' "$PVE_NET_BACKUP"

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

Затем соберите исходные данные:

pveversion -v
uname -r
ip -br link
ip -br address
ip -4 route
bridge link show
cat /etc/network/interfaces
ls -la /etc/network/interfaces.d/
journalctl -b -u networking --no-pager -n 100

pveversion -v показывает версии компонентов Proxmox, а uname -r — действительно загруженное ядро. Они нужны вместе: установленное новое ядро не обязательно уже используется.

В выводе ip найдите адрес управления и физический порт. В конфигурации посмотрите, какой интерфейс указан в bridge-ports или bond-slaves. Если в основном файле есть строки source, прочитайте и подключаемые файлы: часть настроек может находиться там.

Перед очередной перезагрузкой сохраните журнал текущей загрузки:

journalctl -b --no-pager > /root/pve-boot-before-network-repair.log

Так останутся сообщения об исходной ошибке, даже если после перезапуска симптомы изменятся.

После обновления изменилось имя сетевого интерфейса

Это подтверждённый сценарий, встречающийся в обсуждениях обновлений Proxmox. Например, после перехода на 8.2 пользователи обнаруживали, что мост по-прежнему ссылается на старое имя порта. У нескольких участников связь восстановилась после исправления ссылок в конфигурации.

Характерное сообщение в журнале:

error: vmbr0: bridge port eno1 does not exist

Оно означает, что в настройках моста указан eno1, но система не нашла интерфейс с таким именем. Возможны две причины: порт переименован либо устройство не появилось из-за проблемы с драйвером. Сначала различите их.

Как найти правильный порт

ip -br link
lspci -nnk
ethtool -i enp3s0
ethtool -P enp3s0

Здесь и далее enp3s0 — условное имя: подставьте интерфейс, который действительно существует на вашем сервере. Команды ethtool показывают сведения о драйвере и постоянный MAC-адрес, если устройство поддерживает их получение.

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

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

Что исправить в конфигурации

Когда соответствие портов установлено, откройте файл:

nano /etc/network/interfaces

Замените старое имя физического интерфейса в его объявлении и в ссылках на него. Для простого моста это bridge-ports; при использовании bond — также bond-slaves. Проверьте связанные VLAN и пользовательские команды pre-up/post-up.

Ниже условный пример обычного моста. Адреса из диапазона 192.0.2.0/24 приведены только для документации — использовать их вместо выданных провайдером нельзя.

iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.0.2.10/24
    gateway 192.0.2.1
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0

В такой схеме адрес управления находится на vmbr0, а физический порт работает без собственного IP. Отсутствие IP у enp3s0 здесь нормально. Назначение того же адреса одновременно порту и мосту создаст дополнительную проблему.

Если причиной оказалось только переименование, сохраните прежние IP, префикс сети, шлюз и имя моста. Для management VLAN или routed-схемы расположение адреса может быть другим — восстанавливайте свою конфигурацию.

Как применить исправления и сохранить их после перезагрузки

Сначала проверьте interfaces.new

Proxmox может хранить ещё не применённые изменения в /etc/network/interfaces.new. При загрузке служба pvenetcommit переносит их в основной файл. Поэтому ручное исправление interfaces способно исчезнуть после следующего перезапуска.

ls -l /etc/network/interfaces.new
diff -u /etc/network/interfaces /etc/network/interfaces.new

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

mv /etc/network/interfaces.new "$PVE_NET_BACKUP/interfaces.new.deferred"

Если файл появился при запланированном закреплении имён интерфейсов, его нужно рассматривать вместе с соответствующими файлами .link. Изолированное удаление одного файла может рассогласовать будущие имена портов и конфигурацию сети.

Проверьте синтаксис и примените настройки

При установленном ifupdown2 сначала выполните:

ifreload -a -s

Это проверка синтаксиса. Она не подтверждает правильность IP, шлюза, VLAN или выбранного физического порта. Если есть ошибки, исправьте их до применения.

Затем, с открытой независимой консолью:

ifreload -a

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

Не используйте последовательность ifdown vmbr0 и ifup vmbr0 как универсальный способ восстановления: она может оборвать трафик гостей, а повторный подъём моста не всегда возвращает их подключения.

Если ifreload отсутствует, проверьте наличие пакета:

dpkg-query -W ifupdown2

Без сети установка из репозитория может быть недоступна. Один из вариантов применения проверенной конфигурации — согласованная перезагрузка через консоль, предварительно разобравшись с interfaces.new. На работающем узле сначала подготовьте остановку или перенос гостей.

Как отменить неудачную правку

Для возврата основного файла из сделанной копии:

cp -a "$PVE_NET_BACKUP/interfaces" /etc/network/interfaces
ifreload -a -s

После успешной проверки отдельно выполните ifreload -a. Если меняли подключаемые файлы, восстановите и их. В новой консольной сессии сначала заново задайте PVE_NET_BACKUP равным записанному пути.

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

Proxmox Network is unreachable: как проверить маршрут и шлюз

Локальное сообщение connect: Network is unreachable при обращении к IP обычно означает, что система не смогла выбрать пригодный маршрут для этого соединения. Оно не доказывает неисправность сетевой карты и не исправляется заменой DNS.

ip -4 address show
ip -4 route
ip -4 route get 1.1.1.1

Последняя команда показывает, какой путь ядро выбрало бы до внешнего IPv4-адреса. Она сама не отправляет проверочный пакет.

Для условного примера выше ожидается маршрут примерно такого вида:

default via 192.0.2.1 dev vmbr0
192.0.2.0/24 dev vmbr0 proto kernel scope link src 192.0.2.10

• Нет маршрута по умолчанию, но локальная подсеть доступна. Для доступа за её пределы восстановите выданный шлюз в строке gateway соответствующего интерфейса и примените конфигурацию. Изолированному узлу, которому внешняя сеть не требуется, default route может быть не нужен.
• Выбран неверный интерфейс или исходный адрес. Сопоставьте маршрут с расположением адреса управления и прежней конфигурацией. При нескольких каналах проверьте также ip rule show и ip route show table all: выбор пути может зависеть от отдельных правил маршрутизации.
• Нет нужного адреса либо интерфейс выключен. Сначала восстановите его настройку и запуск. Добавление default route не заменяет работающий интерфейс.
• Маршрут выбран правильно. Переходите к проверке шлюза и внешней связности.

Команда ip route add меняет текущее состояние системы. Чтобы восстановление пережило перезагрузку, соответствующая настройка должна присутствовать и в постоянной конфигурации.

Не подбирайте шлюз и маску наугад. У выделенного сервера может быть адрес /32, отдельный маршрут до шлюза или другая схема провайдера. Замена /32 на /24 и добавление onlink без понимания маршрутизации способны нарушить доступ.

Маршрут есть, но шлюз не отвечает

Подставьте настоящий адрес шлюза и интерфейс, через который он доступен:

ping -4 -c 3 192.0.2.1
ip neigh show dev vmbr0

Для обычного Ethernet-подключения состояния INCOMPLETE или FAILED у шлюза после попытки обращения означают, что не удалось определить его MAC-адрес. Проверяйте выбранный порт, VLAN, префикс, адрес шлюза и настройки коммутатора.

Наличие MAC-адреса, в том числе со статусом STALE, само по себе не является ошибкой. Отсутствие ответа на ping тоже не доказывает разрыв: ICMP может фильтроваться. Сопоставляйте его с результатами реальных соединений и проверкой со стороны провайдера.

Сообщение Destination Host Unreachable отличается от локального connect: Network is unreachable. Посмотрите, какой адрес прислал ответ: это помогает понять, возникла проблема на самом узле или дальше по маршруту.

IPv4 работает, а ошибка остаётся при обращении по имени

Приложение может пытаться использовать IPv6. Проверьте семейства адресов отдельно:

ip -6 address show
ip -6 route
getent ahostsv4 example.com
getent ahostsv6 example.com

Если исправный IPv4-путь существует, а IPv6-маршрута нет, разбирайтесь с IPv6-настройкой и выбором адреса в конкретном приложении. Глобальное отключение IPv6 не является обязательным шагом восстановления.

Физический порт существует, но линка нет

ip link show enp3s0
ethtool enp3s0
ethtool -i enp3s0

Флаг UP означает, что интерфейс административно включён. Флаг LOWER_UP у физического Ethernet-порта и строка Link detected: yes указывают на обнаруженный линк. Это ещё не подтверждает правильность VLAN, IP и маршрутов.

Если порт включён, но показывает NO-CARRIER или Link detected: no, проверьте кабель, модуль SFP, порт коммутатора и согласование соединения. На арендованном сервере передайте провайдеру имя порта, MAC и вывод ethtool. После смены ядра возможна и проблема драйвера — её проверяют по журналу и сравнению загрузок.

Команда ip link set enp3s0 up может включить порт для диагностики, но не исправляет привязку моста, адреса и постоянную конфигурацию. Поэтому ситуация «стал UP, но сеть не появилась» вполне возможна.

Сетевая карта исчезла или сеть не запускается с новым ядром

Если нужного интерфейса нет в ip link, проверьте обнаружение оборудования и сообщения ядра:

lspci -nnk
journalctl -b -k --no-pager

Для PCI/PCIe-карты найдите соответствующее устройство и строку Kernel driver in use. Если устройство обнаружено, но сетевой драйвер не работает, изучите сообщения об ошибках загрузки модуля, firmware и инициализации. Если драйвером указан vfio-pci, проверьте настройки проброса оборудования: такой порт может быть передан гостю.

Если карта отсутствует и в списке PCI-устройств, одной правкой interfaces её не вернуть. Нужна проверка аппаратного обнаружения, BIOS и оборудования. Для USB-адаптера вместо lspci используется lsusb.

Как временно загрузить предыдущее ядро

1. Сохраните журнал неудачной загрузки и текущую конфигурацию.
2. Подготовьте перезагрузку: остановите или перенесите работающие гости, учитывая устройство кластера и хранилища.
3. Через независимую консоль откройте меню загрузчика. В GRUB предыдущие версии обычно находятся в Advanced options; в systemd-boot выберите соответствующую запись ядра.
4. Загрузите ранее работавшее установленное ядро, подходящее вашей версии Proxmox.
5. Проверьте uname -r, имена интерфейсов, маршруты и внешнюю доступность.

Список ядер, известных инструменту загрузки Proxmox, можно посмотреть командой:

proxmox-boot-tool kernel list

Если сеть вернулась, это ещё не доказывает ошибку драйвера. Старое ядро могло вернуть прежнее имя порта. Сравните вывод ip -br link и журналы обеих загрузок.

Выбор предыдущего ядра не откатывает обновлённые пакеты, сетевые файлы и всю систему. После перехода между основными версиями нельзя считать любое старое ядро совместимым. Если требуется временно закрепить проверенную версию для последующих загрузок, используйте механизм pin в proxmox-boot-tool по документации своей установки и запланируйте снятие закрепления после устранения причины.

Когда предыдущего ядра нет, не удаляйте текущее и не устанавливайте случайный драйвер из стороннего скрипта. Сначала определите точную модель карты, версию ядра и ошибку — от этого зависит дальнейший способ восстановления.

Интерфейсы на месте, но служба networking не стартовала

Иногда сеть не поднимается из-за зависшей команды или другой службы, от которой зависит её запуск:

systemctl --failed --no-pager
systemctl status networking ifupdown2-pre systemd-udev-settle --no-pager -l
journalctl -b -u networking -u ifupdown2-pre -u systemd-udev-settle --no-pager -n 150

Набор служб зависит от установленной версии. Отсутствие отдельного unit само по себе не доказывает неисправность.

• Сообщение о несуществующем bridge port. Вернитесь к сопоставлению имён интерфейсов.
• Ошибка конкретной команды pre-up или post-up. Проверьте эту команду и вызываемую службу. Не удаляйте все обработчики: среди них могут быть необходимые маршруты и правила NAT.
• Dependency failed или ожидание udev. Найдите первоначальную ошибку устройства в журнале загрузки. Причиной может оказаться оборудование, не связанное напрямую с сетевой картой.

В обсуждении перехода Proxmox 8.4 → 9 пользователи подтвердили зависание из-за прежней строки post-up /usr/bin/systemctl restart frr.service в конфигурации OpenFabric. После её удаления система загрузилась; возврат к старому ядру одному из участников не помог. Это решение относится к конкретной схеме с FRR — службой динамической маршрутизации. Для такого кластера правку нужно сопровождать проверкой запуска FRR, маршрутов и состояния Ceph.

Другой подтверждённый случай в 2026 году оказался связан с инициализацией накопителя Fusion-io и его стороннего драйвера: сбой зависимости мешал запуску сети. Поэтому сообщение об отказе networking — повод прочитать предыдущие ошибки, а не автоматически менять сетевую карту.

Если после обновления отсутствуют команды или службы Proxmox, проверьте также состояние пакетов:

dpkg --audit
pveversion -v

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

SSH работает, но веб-интерфейс Proxmox не открывается

Панель Proxmox обычно доступна по HTTPS на TCP-порту 8006. Если SSH на тот же адрес работает, сначала проверьте службу панели:

systemctl status pveproxy --no-pager -l
ss -lntp 'sport = :8006'
journalctl -b -u pveproxy --no-pager -n 100

Пустой вывод ss означает, что на порту никто не слушает. Если слушатель есть, обратите внимание на адрес: доступ может быть ограничен конкретным IP.

Проверьте HTTP-ответ локально. Если служба слушает только определённый адрес, используйте его вместо 127.0.0.1:

curl -k -sS --connect-timeout 5 -o /dev/null -w '%{http_code}\n' https://127.0.0.1:8006/

Код 200 подтверждает получение страницы. Другие HTTP-коды тоже показывают, что соединение дошло до HTTP-службы, но требуют разбора ответа. Параметр -k здесь используется только для локальной диагностики сертификата.

Если pveproxy остановлен или завершился с ошибкой, сначала устраните причину из журнала, затем перезапустите службу:

systemctl restart pveproxy

Повторите локальный запрос и откройте новое соединение с другого компьютера. Перезапуск может оборвать текущие веб-консоли.

Если локально панель отвечает, а снаружи нет, проверьте правила Datacenter → Firewall, узел → Firewall, внешнюю фильтрацию провайдера и ограничения в /etc/default/pveproxy. Правила Proxmox находятся в /etc/pve/firewall/cluster.fw и /etc/pve/nodes/ИМЯ_УЗЛА/host.fw.

Для доступа должен разрешаться TCP 8006 с вашего административного адреса или VPN. После переименования порта проверьте правила, привязанные к старому имени. Учитывайте используемую реализацию firewall: pve-firewall и proxmox-firewall — разные службы. Сбрасывать все правила или переключать реализацию для проверки не требуется.

По IP всё работает, а доменные имена не открываются

getent ahostsv4 example.com
cat /etc/resolv.conf

Если рабочее соединение по IP подтверждено, а getent не возвращает адреса, проверьте DNS-серверы и их доступность. В панели Proxmox настройки находятся в разделе узла System → DNS.

В resolv.conf должны быть указаны доступные из этой сети резолверы. Для инфраструктуры с внутренними именами нужен DNS, который знает соответствующие зоны: случайная замена его публичным сервером может нарушить работу внутренних сервисов.

После исправления повторите getent и исходный запрос к нужному ресурсу. Если не работает обращение даже к IP DNS-сервера из-за отсутствующего маршрута, сначала восстановите маршрутизацию.

Хост доступен, но у виртуальных машин или контейнеров нет сети

Проверьте настройки пострадавшего гостя: у ВМ — Hardware → Network Device, у контейнера — Network. Сверьте мост, VLAN tag, состояние виртуального подключения и настройку firewall с рабочей конфигурацией до обновления.

На узле проверьте Linux-мосты и VLAN:

bridge link show
bridge vlan show

Для стандартного моста внешний порт или bond должен быть связан с нужным vmbr. При этом гостевой интерфейс может подключаться через дополнительные мосты firewall — отсутствие прямой связи tap с vmbr не всегда является ошибкой.

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

Затем выполните проверки адреса и маршрута внутри гостевой ОС. Исправная сеть хоста не гарантирует, что у ВМ есть правильный IP и шлюз. Если используется routed-схема или NAT, дополнительно сверьте маршруты, пересылку пакетов и правила преобразования адресов с прежними настройками.

Для bond проверьте состояние его участников в /proc/net/bonding/. Если используется LACP, согласованная конфигурация должна сохраняться и на коммутаторе. Подмена bond одним случайным портом не является универсальным восстановлением.

Как убедиться, что доступ восстановлен полностью

Открытие панели — первый результат. До завершения работ проверьте:

1. Адрес управления находится на правильном интерфейсе, а маршрут до административного компьютера и нужных внешних сетей выбирается корректно.
2. С другого компьютера открываются новое SSH-соединение и панель Proxmox.
3. Работают DNS и соединения с необходимыми репозиториями и внешними сервисами.
4. Доступны гости в каждой используемой сети или VLAN.
5. На кластерном узле восстановлены связь с другими узлами и доступ к хранилищам; для Ceph проверено состояние кластера.
6. В журнале нет повторяющихся ошибок запуска сети, драйвера и зависимостей.
7. Рабочие изменения сохранены в постоянной конфигурации и не будут заменены устаревшим interfaces.new.

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

Что подготовить перед следующим обновлением

Сохраните вне узла сетевую конфигурацию, соответствие физических портов и MAC-адресов, настройки VLAN и bond, версии ядра и сведения о сторонних драйверах. Отдельно проверьте резервные копии гостей и способ их восстановления. Копия interfaces не заменяет резервное копирование виртуальных машин.

Перед переходом между основными версиями используйте официальную инструкцию и проверочный инструмент для этого перехода. Например, для 8 → 9 применяется pve8to9 --full. Разберите предупреждения до обновления и проверьте доступ к консоли заранее.

Для предотвращения переименований в поддерживающих его версиях Proxmox доступен pve-network-interface-pinning. Он создаёт правила закрепления имён и обновляет связанные настройки. Это плановое изменение: сначала ознакомьтесь с процедурой, проверьте подготовленные различия и выполняйте перезагрузку через независимую консоль.

Особенно внимательно проверьте общие правила firewall в /etc/pve/firewall/cluster.fw: инструмент не заменяет в них имена автоматически. Закрепление имён помогает при их изменении, но не исправляет неисправный драйвер или физический порт.

Что отправить в поддержку, если сеть не восстановилась

Чтобы специалист мог продолжить диагностику, приложите:

• Версии Proxmox до и после обновления, вывод pveversion -v и uname -r.
• Уточнение, что недоступно: хост, панель, все гости или отдельная сеть.
• Вывод ip -br link, ip -br address, ip -4 route и bridge link show.
• Файл interfaces, подключаемые сетевые файлы и наличие interfaces.new.
• Модель карты, сведения о драйвере и сообщения журнала текущей загрузки.
• Результат загрузки предыдущего ядра, если она выполнялась.
• Сведения о VLAN, bond, routed-подсети, SDN, Ceph и HA, если они используются.

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

Какой доступ предусмотреть на выделенном сервере

Для Proxmox возможность попасть в консоль при неработающей сети стоит учитывать ещё при выборе оборудования. У выделенных серверов HSTQ IPMI предоставляется на поддерживаемых платформах, а временный KVM — по заявке и доступности. Перед заказом уточните вариант для выбранной конфигурации и порядок подключения.

Базовая поддержка HSTQ охватывает оборудование и сеть; администрирование оформляется отдельно. Если нужна помощь с обновлениями Proxmox, настройкой сети и восстановлением доступа, заранее согласуйте состав этих работ для своего сервера.