Proxmox — «Connection refused» на 8006 після оновлень: що перевірити в першу чергу

Швидкий план діагностики (перші 10 хвилин)

Це порядок, що мінімізує час до виявлення кореневої причини в продакшені. Він орієнтований на відмови, які виникають після оновлень: проблеми з перезапуском сервісів, сертифікатами, змінами фаєрволу та залежностями кластера.

Хвилини 0–2: Підтвердіть, що симптом локальний, а не «мережа»

1. З вашої робочої станції: чи працює ssh? Якщо SSH теж падає, це не проблема лише «8006»; це маршрутизація, лінк, IP або хост взагалі недоступний.
2. На самому хості Proxmox: протестуйте його порт 8006 за допомогою curl. Якщо він не може достукатися до себе — проблема майже точно в pveproxy, який не слухає, або в локальній блокуванню.

Хвилини 2–5: Перевірте, чи щось слухає на 8006

1. Використайте ss, щоб побачити, чи прив’язаний 8006. Якщо нічого не слухає — не чіпайте фаєрвол. Спочатку виправте pveproxy.
2. Перевірте systemctl status pveproxy. Якщо він впав — читайте помилки і переходьте одразу до логів (journalctl -u pveproxy).

Хвилини 5–7: Валідність залежностей керуючого стеку

1. Перевірте pvedaemon та pvestatd. UI може «підключатися», але поводитися некоректно, якщо ці сервіси мертві; але «connection refused» зазвичай — це pveproxy.
2. Перевірте вільне місце на диску та тиск індексів inode. Заповнені кореневі файлові системи та розділи логів вбивають демони по‑непомпезному.

Хвилини 7–10: Фаєрвол, потім кластер, потім сертифікати

1. Фаєрвол: підтвердіть, що pve-firewall та правила nftables/iptables не відкидають tcp/8006.
2. Стан кластера: якщо хост у кластері — кворум і corosync можуть непрямо блокувати керування (особливо навколо config FS).
3. Сертифікати: пошкоджений або недоступний SSL‑ключ/сертифікат може не дозволити pveproxy запуститися.

Робіть це в порядку. Якщо ви почнете з «просто перезавантажити все», ви можете перетворити просту відмову на хаос. Так, я знаю — перезапуск дає відчуття роботи. Це також дорослий варіант дмухання на картридж Nintendo.

Що насправді означає «Connection refused» на 8006

Браузери драматизують. «Connection refused» — це не «повільно», не «TLS‑помилка» і не «автентифікація не пройшла». Зазвичай це одна з трьох речей:

• Немає процесу, що слухає на цьому IP:порті. Ядро відповідає RST (reset), і клієнт повідомляє «refused».
• Локальний фаєрвол активно відхиляє підключення (також часто RST). Це рідше, ніж люди думають, але трапляється — особливо коли правила змінилися під час оновлень.
• Реверс‑проксі / невідповідність socket activation (менш поширено). Для Proxmox релевантний демон — pveproxy, який біндиться на 8006 і обробляє TLS.

Якщо проблема була б «blocked» (DROP), частіше ви бачили б таймаути. Якщо б це була «TLS‑пошкодження», зазвичай підключення відбувалось би, а потім з’явилась би помилка сертифіката, а не «refused». Тож трактуйте «refused» як сильний сигнал: порт недоступний на рівні TCP accept.

Є також тонкий варіант: 8006 слухає, але тільки на неправильному інтерфейсі (наприклад, прив’язаний до 127.0.0.1). З боку це теж може виглядати як відмова. Ми це перевіримо явно.

Цікаві факти та контекст (бо це має історію)

• Порт 8006 не був обраний з естетичних причин. Історично Proxmox використовував високий нестандартний порт, щоб не конфліктувати з іншими веб‑стеками на тому ж хості.
• pveproxy — це демон на Perl. Він не модний, але боєздатний і тісно інтегрований з API та системою автентифікації Proxmox.
• Proxmox базується на Debian. Багато інцидентів «після оновлень» — це фактично зміни на рівні Debian: kernel, libc, OpenSSL, поведінка systemd.
• Proxmox змінював бекенд фаєрволу з часом. Перехід Debian від iptables до nftables неодноразово був джерелом ситуацій «правила є, але не там, де ви думаєте».
• Конфігурація кластера — це файловий простір. Конфігурація кластера Proxmox живе у розподіленій файловій системі (pmxcfs), і коли вона нездорова — процеси керування швидко дивуються.
• За замовчуванням TLS став більш строгим. OpenSSL і суміжні бібліотеки регулярно забороняють застарілі шифри/протоколи; демони, що не можуть коректно завантажити ключі/сертифікати, часто падають жорстко.
• Systemd зробив сервіси більш спостережуваними. Це плюс. Мінус — він також зробив «цикли перезапуску» дуже ефективними, тож зламаний демон може впасти 50 разів, поки ви навіть не помітите.
• Оновлення Proxmox — це не лише оновлення UI. Вони регулярно зачіпають інструменти зберігання (ZFS), мережеві утиліти (ifupdown2) і віртуалізацію (QEMU/KVM). Ви оновлюєте малий дата‑центр, а не веб‑додаток.

Одна ідея, яку варто тримати при собі, переказана від Werner Vogels: «Все рано чи пізно ламається; стійкість походить з того, що приймаєш це і проектуєш операції відповідно.» (парафраз)

Практичні завдання: команди, виводи, рішення (12+)

Ось перевірки, які я реально виконую, коли перебуваю на чергуванні і хтось каже «Proxmox впав». Кожне завдання включає: команду, реалістичний фрагмент виводу, що це означає, і яке рішення робити далі.

Завдання 1: Переконайтеся, що хост доступний і ви на правильному сервері

cr0x@server:~$ hostnamectl
 Static hostname: pve01
       Icon name: computer-server
         Chassis: server
      Machine ID: 1c3f0c0c9b0d4c2d9d2a2e0d1a0cbeef
         Boot ID: 6b77c2a5a1a74c469c9c4a9b3d9d1234
Operating System: Debian GNU/Linux 12 (bookworm)
          Kernel: Linux 6.8.12-2-pve
    Architecture: amd64

Означає: Ви на тому хості Proxmox, який думаєте, і знаєте контекст ОС/ядра після оновлень.

Рішення: Якщо ядро змінилося, майте на увазі: імена NIC, драйвери та бекенди фаєрволу можуть змінитися після перезавантаження.

Завдання 2: Підтвердьте, чи 8006 слухає і на якому IP

cr0x@server:~$ ss -lntp | grep -E ':8006|State'
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096         0.0.0.0:8006       0.0.0.0:*     users:(("pveproxy",pid=1432,fd=6))

Означає: pveproxy слухає на всіх інтерфейсах. «Connection refused» зовні навряд чи означає «сервіс упав».

Рішення: Якщо бачите тільки 127.0.0.1:8006, трактуйте це як проблему прив’язки/інтерфейсу. Якщо нічого не бачите — переходьте до Завдання 4 (стан сервісу) і Завдання 5 (логи).

Завдання 3: Протестуйте локально за допомогою curl (виключає мережу)

cr0x@server:~$ curl -k -sS -o /dev/null -w '%{http_code}\n' https://127.0.0.1:8006/
200

Означає: Веб‑ендпоінт відповідає локально. Якщо віддалені користувачі отримують refusal — проблема, майже напевно, у фаєрволі/маршрутизації/VIP, а не в сервісах Proxmox.

Рішення: Перейдіть до перевірок фаєрволу (Завдання 10/11) і перевірки інтерфейсів (Завдання 8/9).

Завдання 4: Перевірте здоров’я pveproxy через systemd (не гадати)

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2025-12-25 10:44:02 UTC; 45s ago
    Process: 1519 ExecStart=/usr/bin/pveproxy start (code=exited, status=1/FAILURE)
   Main PID: 1519 (code=exited, status=1/FAILURE)

Dec 25 10:44:02 pve01 pveproxy[1519]: starting server
Dec 25 10:44:02 pve01 pveproxy[1519]: can't load certificate '/etc/pve/local/pve-ssl.pem': No such file or directory
Dec 25 10:44:02 pve01 systemd[1]: pveproxy.service: Main process exited, code=exited, status=1/FAILURE
Dec 25 10:44:02 pve01 systemd[1]: pveproxy.service: Failed with result 'exit-code'.

Означає: Явна відмова: відсутній файл сертифіката під /etc/pve. Це вказує на те, що pmxcfs/кластерна файлова система не змонтована/нездорова, або генерація сертифікатів була перервана.

Рішення: Перейдіть до Завдань 6 та 7 (pmxcfs і перевірка /etc/pve), потім генеруйте сертифікати, коли /etc/pve буде в порядку.

Завдання 5: Читати логи з контекстом (journalctl — ваш друг)

cr0x@server:~$ journalctl -u pveproxy -b --no-pager -n 60
Dec 25 10:44:02 pve01 pveproxy[1519]: starting server
Dec 25 10:44:02 pve01 pveproxy[1519]: can't load certificate '/etc/pve/local/pve-ssl.pem': No such file or directory
Dec 25 10:44:02 pve01 systemd[1]: pveproxy.service: Main process exited, code=exited, status=1/FAILURE
Dec 25 10:44:02 pve01 systemd[1]: pveproxy.service: Failed with result 'exit-code'.
Dec 25 10:44:12 pve01 systemd[1]: pveproxy.service: Scheduled restart job, restart counter is at 5.

Означає: Він зациклюється на рестарті. Це може викликати каскадні проблеми (спам логів, навантаження CPU), але корінь — перший рядок помилки.

Рішення: Виправте проблему з сертифікатом/шляхом/pmxcfs. Не перезапускайте без кінця — ви просто створюєте тепло.

Завдання 6: Перевірте, чи працює pmxcfs (бо /etc/pve не «нормальна»)

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled; preset: enabled)
     Active: active (running) since Wed 2025-12-25 10:42:21 UTC; 3min ago
   Main PID: 602 (pmxcfs)
      Tasks: 7 (limit: 154322)
     Memory: 52.1M
        CPU: 1.824s

Означає: pmxcfs працює. Це не гарантує його повного здоров’я, але виключає очевидний кейс «сервіс впав».

Рішення: Якщо він впав — виправляйте його перш за все (зберігання/повний диск/кворум). Якщо працює — підтвердіть, що /etc/pve змонтовано і заповнено (Завдання 7).

Завдання 7: Переконайтеся, що /etc/pve змонтовано (а не порожня папка)

cr0x@server:~$ mount | grep ' /etc/pve '
pve:/etc/pve on /etc/pve type fuse.pve (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Означає: Воно змонтовано через FUSE. Добре. Тепер перевірте, чи існує очікуваний файл сертифіката.

Рішення: Якщо рядка монтування немає — ви не бачите файлову систему кластера; сервіси Proxmox працюватимуть некоректно. Дослідіть запуск pmxcfs і кворум/кластери (Завдання 12/13).

Завдання 8: Переконайтеся, що IP керування все ще на інтерфейсі (оновлення + перезавантаження люблять сюрпризи)

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.20.10.11/24
vmbr0            UP             10.20.10.11/24 fe80::2a0:98ff:fe12:3456/64

Означає: IP присутній. Зверніть увагу: однаковий IP на фізичному NIC і мосту може бути легітимним залежно від конфігурації, але також може бути помилкою після переробки інтерфейсів.

Рішення: Якщо очікуваного IP немає — виправляйте мережу в першу чергу. UI Proxmox не прив’язується до IP, якого у вас немає.

Завдання 9: Перевірте маршрутизацію (бо «він пінгується» — це не маршрутна таблиця)

cr0x@server:~$ ip route
default via 10.20.10.1 dev vmbr0 proto kernel onlink
10.20.10.0/24 dev vmbr0 proto kernel scope link src 10.20.10.11

Означає: Маршрут за замовчуванням існує. Якщо ваша станція керування в іншому підмережі — це має бути правильно налаштовано, щоб дістатися до 8006.

Рішення: Неправильний маршрут або відсутній шлях — виправляйте мережеву конфігурацію. Не звинувачуйте сервіси Proxmox за помилки маршрутизатора.

Завдання 10: Перевірте стан фаєрволу Proxmox (PVE firewall може відкидати 8006)

cr0x@server:~$ pve-firewall status
Status: enabled/running

Означає: PVE firewall активний. Це нормально, але значить, що правила мають значення.

Рішення: Якщо ввімкнено — інспектуйте набір правил і підтвердіть, що 8006 дозволено на інтерфейсі керування. Якщо вимкнено — все одно перевірте nftables/iptables (Завдання 11).

Завдання 11: Перегляньте правила nftables на предмет явних відхилень (refused часто = REJECT)

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    iif "lo" accept
    ct state established,related accept
    tcp dport 22 accept
    tcp dport 8006 reject with tcp reset
  }
}

Означає: Хтось (або щось) явно відхиляє 8006 з TCP reset. Це дає клієнтам «Connection refused».

Рішення: Виправте правило (видаліть reject або замініть на accept для ваших адміністраторських мереж). Не «флеште все тимчасово», якщо ви не любите несподіване відкриття доступу.

Завдання 12: Перевірте corosync/kворум (в кластері хости можуть поводитися як привиди без нього)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name: prod-cluster
Config Version: 42
Transport: knet
Secure auth: on

Quorum information
------------------
Date: Wed Dec 25 10:47:11 2025
Quorum provider: corosync_votequorum
Nodes: 3
Node ID: 0x00000001
Ring ID: 1.2a
Quorate: Yes

Означає: Кворум в порядку. Якби було Quorate: No, багато залежних від конфіга сервісів можуть застопоритися або відмовитись писати, і ви побачите вторинні збої.

Рішення: Якщо немає кворуму — вирішіть: відновити кворум (переважно) або безпечно ізолювати вузол. Уникайте стратегії «просто перезавантажимо інший вузол».

Завдання 13: Перевірте дисковий простір та іноди (нудно, часто, смертельно)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/mapper/pve-root   94G   94G     0 100% /

Означає: Коренева файлова система повна. Сервіси, яким потрібно писати PID, логи або стан, виходять з ладу такими способами, що здаються не пов’язаними з диском.

Рішення: Звільніть простір негайно і перезапустіть постраждалі сервіси. Також знайдіть, що росло (Завдання 14) і виправте підґрунтя поведінки логів/бекапів.

Завдання 14: Визначте, що «жере» кореневу файлову систему

cr0x@server:~$ du -xhd1 /var | sort -h
1.1G	/var/cache
2.4G	/var/log
38G	/var/lib

Означає: Щось під /var/lib велике. На Proxmox кандидатами є ISO‑сховище, образи контейнерів, бекапи або runaway journald.

Рішення: Розкопайте далі (du -xhd1 /var/lib) і видаліть/перемістіть правильного винуватця. Не видаляйте випадково конфіги кластера. Там лежить жаль.

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

cr0x@server:~$ ls -l /etc/pve/local/pve-ssl.pem /etc/pve/local/pve-ssl.key
-rw-r----- 1 root www-data  3882 Dec 25 10:10 /etc/pve/local/pve-ssl.pem
-rw-r----- 1 root www-data  1704 Dec 25 10:10 /etc/pve/local/pve-ssl.key

Означає: Сертифікат і ключ існують і мають правдоподібні права доступу.

Рішення: Якщо відсутні або пошкоджені — регенеруйте (Завдання 16). Якщо права неправильні (занадто суворі) — виправте власника/режим, щоб pveproxy міг їх читати.

Завдання 16: Регенерація сертифікатів Proxmox (коли проблеми з сертифікатом не дають pveproxy стартувати)

cr0x@server:~$ pvecm updatecerts --force
Generating new certificates...
Restarting pveproxy...
Restarting pvedaemon...
done

Означає: Proxmox згенерував кластер‑свідому пару сертифікатів і перезапустив релевантні демони.

Рішення: Перевірте systemctl status pveproxy і підтвердіть прослуховування 8006 (Завдання 2). Якщо все ще падає — повертайтеся до логів; не повторюйте це без кінця.

Завдання 17: Перевірте конфлікти портів (рідко, але варто глянути)

cr0x@server:~$ lsof -nP -iTCP:8006 -sTCP:LISTEN
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pveproxy 1432 root    6u  IPv6  31245      0t0  TCP *:8006 (LISTEN)

Означає: Правильний процес зайняв порт.

Рішення: Якщо щось інше слухає 8006 — зупиніть його або переналаштуйте. Proxmox очікує володіти цим портом; сперечатися з цим — це спосіб життя.

Завдання 18: Перевірте досяжність з іншого хоста в тій самій підмережі

cr0x@server:~$ nc -vz 10.20.10.11 8006
Connection to 10.20.10.11 8006 port [tcp/*] succeeded!

Означає: TCP‑з’єднання працює. Якщо браузер все ще видає помилку — ймовірно проблема TLS/trust або кеш браузера, або ви влучаєте не в той IP/DNS.

Рішення: Перевірте DNS‑резолюцію і ціль у браузері. Також перевірте, чи не використовуєте ви VIP, зворотний проксі або перенаправлення портів, які могли змінитися під час мережевих оновлень.

Ще одна операційна істина: «Connection refused» рідко є таємницею і часто — проваленням по чеклісту. Це хороша новина. Ви можете виправити це без поезії.

Жарт №1: Якщо ваш план після оновлення — «ми просто відкотимо», — вітаю — ви відкрили подорож у часі, але тільки для версій пакетів.

Три корпоративні міні‑історії з практики

Інцидент №1: Помилкове припущення («Певно, фаєрвол»)

Середня SaaS‑компанія мала три‑вузловий кластер Proxmox для внутрішніх CI‑ раннерів і staging. Після рутинного оновлення на одному вузлі веб‑UI перестав відповідати на 8006. Інженер на чергуванні спершу подумав звичне: «оновлення безпеки налаштувало фаєрвол». Вони вимкнули сервіс фаєрволу і все одно отримували «Connection refused». Це мало бути підказкою, але адреналін — переконливий наркотик.

Інженер тоді повністю скинув правила nftables. Нода стала доступною на 8006 приблизно на тридцять секунд, потім знову зникла. «Отже, фаєрвол», — думали вони. Насправді ж pveproxy зациклювався на рестарті, коротко біндячись на 8006 між падіннями. Скидання правил змінило лише таймінг, а не причинний ланцюг.

Справжня коренева причина лежала на поверхні: коренева файлова система була заповнена на 100%. pveproxy не міг писати свій стан, pvedaemon почав скаржитися, і systemd виконав свою ефективну хореографію падіння. Місце для фаєрвол‑козла обійшло їх на годину, плюс аудиторський висновок, бо нода працювала з фактично відкритою політикою input довше, ніж треба було.

Виправлення не було винахідливим. Вони звільнили місце під /var/log, провели ротацію журналів, перезапустили сервіси й додали моніторинг використання файлової системи. Постмортем був різкий: «Ми взяли за причину кореляцію (оновлення → фаєрвол). Ми не перевірили стан сокета насамперед.»

Інцидент №2: Оптимізація, що відкотилася («Задамо політику drop за замовчуванням»)

Велика IT‑команда стандартизувала контур хостів з жорсткими правилами. Одне з змін виглядало акуратно: встановити політику input на drop, а потім явно дозволяти лише потрібні порти. Розумно. Контрольовано. Приємно для аудиту.

Проблема була в імплементації на Proxmox. Вони запушили шаблон nftables, який дозволяв SSH і кілька моніторингових портів, але припустили, що веб‑UI знаходиться за корпоративним зворотним проксі і не потребує прямого доступу до 8006. Це припущення було вірним для більшості середовищ. Воно було хибним для розриву‑доступу, коли зворотний проксі був недоступний — або під час обслуговування, коли адміністратори заходили через jump host і очікували доступ до https://node:8006 напряму.

Після оновлення і перезавантаження Proxmox піднявся, pveproxy слухав на 8006, і локальний curl повертав 200. З jump host‑а все отримувало «Connection refused», бо шаблон робив reject with tcp reset для незаявлених портів. Це деталь, що ввела в оману: помилка «refused» пахне «сервіс впав».

Виправлення не полягало у «відкритті всього». Вони додали вузьке правило allow для 8006 з підмережі jump host‑а і зберегли політику drop. Ще важливіше — задокументували, що порти керування є частиною шляху break‑glass, а не опціональною зручністю. Оптимізація (жорсткіша базова політика) була правильною; помилкою був розгортання без операційних винятків.

Інцидент №3: Нудна практика, що врятувала ситуацію (передперевірки і поетапні ребути)

Команда фінансових послуг керувала Proxmox для VDI і купи внутрішніх сервісів. Вони були консервативні настільки, що це виглядало кумедно: кожне вікно оновлення починалося з передперевірки, збереженої в тікеті і перевіреної другою особою. Це виглядало бюрократією — поки не стало потрібним.

Однієї ночі оновлення включали зміни, що вимагали перезавантаження. Перед перезавантаженням передперевірка захопила: вільний простір, тиск пам’яті, кворум кластера і чи вузол тримає критичні VM. Вона також зберігала «що слухає 8006 зараз» і хеш правил фаєрволу. Нудно. Повторювано. Саме у цьому суть.

Після перезавантаження 8006 відмовляв у з’єднанні. Інженер не почав метатися, бо мав базову лінію: до ребуту nftables мав allow для 8006; після ребуту дозволу не було. Це різко звузило простір пошуку. Проблема була від кон‑фігураційної утиліти, що застосувала невірну роль до цього вузла під час вікна обслуговування.

Вони відкотили роль, відновили правило allow і швидко повернулися онлайн. Постмортем не містив героїзму, лише рядок, який всі ненавидять, але всі потребують: «Наші передперевірки перетворили загадку на diff.» Єдине цікаве — наскільки буденним було відновлення.

Жарт №2: Proxmox UI не «рандомно зламався після оновлень». Воно зламалося за розкладом — просто ви не читали календар.

Типові помилки: симптом → корінь проблеми → виправлення

Це місце, куди йде час, якщо ви не впізнаєте шаблони. Ось повторювані провокатори, налаштовані спеціально для «Connection refused» на 8006 відразу після оновлень.

1) «Connection refused» відразу після ребуту

• Симптом: Браузер каже refused; ping працює; SSH працює.
• Корінь проблеми: pveproxy не вдалося запуститися (відсутній/пошкоджений сертифікат, pmxcfs не змонтовано або синтаксична помилка в конфігу).
• Виправлення: systemctl status pveproxy → journalctl -u pveproxy. Перевірте монтаж /etc/pve; регенеруйте сертифікати через pvecm updatecerts --force лише після того, як /etc/pve здоровий.

2) Локальний curl працює, зовні refused

• Симптом: curl -k https://127.0.0.1:8006 повертає 200; зовнішній браузер отримує refused.
• Корінь проблеми: nftables/iptables відкидає 8006, або сервіс прив’язаний тільки до loopback, або IP перемістився на інший інтерфейс/VLAN.
• Виправлення: Перевірте ss -lntp на адресу прив’язки; перевірте правила фаєрволу (nft list ruleset); підтвердіть IP і маршрути (ip -br addr, ip route).

3) «Раніше працювало», а тепер лише один вузол зламався

• Симптом: Кластер має кілька вузлів; лише оновлений вузол відмовляє на 8006.
• Корінь проблеми: На цьому вузлі /etc/pve застаріло/не змонтовано, проблема з corosync, або вузол завантажився з іншим мережевим конфігом (зміни йменування мостів, відсутній VLAN).
• Виправлення: Перевірте pvecm status, systemctl status pve-cluster, mount | grep /etc/pve і мережеву конфігурацію під /etc/network/interfaces (обережно).

4) «Connection refused» тільки з деяких мереж

• Симптом: Працює з jump host, відмовляє з вашого ноутбука, або навпаки.
• Корінь проблеми: Правила доступу керування специфічні для підмереж; можливо корпоративний шаблон додав явний reject для 8006, крім дозволених діапазонів.
• Виправлення: Підтвердьте за лічильниками nft і порядком правил; додайте явний allow для 8006 з потрібних джерел адміністрування.

5) 8006 «refused» і інші сервіси флапають

• Симптом: Не лише UI — метрики, бекапи або запуск контейнерів теж падають.
• Корінь проблеми: Диск заповнений, вичерпано іноди або файлову систему примусово змонтовано в режимі тільки для читання після помилок.
• Виправлення: df -h, df -i, dmesg -T | tail; усуньте проблеми зі сховищем, потім перезапустіть сервіси.

6) Ви постійно перезапускаєте сервіси і нічого не допомагає

• Симптом: systemctl restart pveproxy «працює», але UI все одно refused; або він відразу падає.
• Корінь проблеми: Перезапуск не виправляє відсутні файли, проблеми з правами або заблокований порт. Він просто змінює часову мітку.
• Виправлення: Зупиніть і читайте логи. Виправте першу рядок помилки. Потім перезапускайте.

Чеклісти / покроковий план (безпечне відновлення)

Це план, якого слідувати, якщо ви хочете повернути UI і не створити побічну шкоду. Він написаний, щоб бути безпечним на автономних хостах і вузлах кластера.

Фаза 1: Визначте область (2–5 хвилин)

1. Переконайтеся в доступності хоста: зайдіть по SSH; підтвердіть правильний хост (hostnamectl).
2. Перевірте локальну доступність UI: curl -k https://127.0.0.1:8006/.
3. Перевірте слухач: ss -lntp | grep :8006.

Якщо 8006 не слухає: переходьте до Фази 2.
Якщо слухає локально, але зовні не працює: переходьте до Фази 4 (мережа/фаєрвол).

Фаза 2: Виправлення сервісу (5–15 хвилин)

1. Статус і логи: systemctl status pveproxy, потім journalctl -u pveproxy -b.
2. Залежності: systemctl status pvedaemon pve-cluster.
3. Перевірте /etc/pve: mount | grep ' /etc/pve ' і ls -l /etc/pve/local/.
4. Санітай диска: df -h /, df -i /. Виправляйте, якщо заповнено, перш ніж робити інші дії.

Фаза 3: Сертифікати і конфігураційна файлова система (за потреби)

1. Якщо файли сертифікатів відсутні або пошкоджені: переконайтеся, що /etc/pve змонтовано і заповнено.
2. Тоді регенеруйте сертифікати: pvecm updatecerts --force.
3. Повторно перевірте слухач: ss -lntp | grep :8006 і локальний curl.

Фаза 4: Фаєрвол і мережевий шлях (коли локально працює, а зовні ні)

1. Підтвердьте адресу прив’язки: якщо це тільки 127.0.0.1:8006, виправте конфіг, що обмежує бінд (рідко; зазвичай не за замовчуванням).
2. Перевірте фаєрвол Proxmox: pve-firewall status. Якщо ввімкнено — підтвердіть правила, що дозволяють 8006 з ваших адміністративних підмереж.
3. Перегляньте nftables: nft list ruleset і шукайте правила з tcp dport 8006, що reject/drop.
4. Перевірте IP і маршрути: ip -br addr, ip route.
5. Тестуйте з іншого хоста: nc -vz <ip> 8006.

Фаза 5: Санітарність кластера (тільки для кластерів)

1. Перевірте кворум: pvecm status.
2. Перевірте corosync: systemctl status corosync і логи за потреби.
3. Уникайте ризикованих «виправлень»: не виривайте вузли з кластера лише щоб повернути UI. Спочатку відновіть мережеве з’єднання між вузлами.

Коли зупинитися і ескалувати

• Якщо бачите помилки файлової системи в dmesg або перемонтування в режимі лише для читання.
• Якщо втрачен кворум кластера і ви не впевнені, які вузли «реальні».
• Якщо хост також є головою сховища (ZFS/NFS/iSCSI) і неправильний крок може вивести з ладу інші сервіси.

ЧаПи

1) Чому «Connection refused» зазвичай означає pveproxy, а не API‑демон?

Бо 8006 — це TLS‑ендпоінт, який обслуговує pveproxy. Якщо цей демон не слухає (або фаєрвол відхиляє) — TCP‑з’єднання не встановиться. Проблеми з pvedaemon зазвичай проявляються як помилки в UI після встановлення з’єднання, а не як відмова.

2) Яка найшвидша перевірка?

ss -lntp | grep :8006. Якщо нічого не слухає — перестаньте думати про маршрутизатори і починайте читати логи pveproxy.

3) Локальний curl працює, але браузер з ноутбука відмовляє. Що робити?

Припустіть фаєрвол або мережевий шлях. Перевірте nftables на reject with tcp reset для 8006, підтвердіть, що IP на правильному інтерфейсі, і протестуйте з хоста в тій самій підмережі за допомогою nc -vz.

4) Можу я просто перезапустити pveproxy і все?

Спробуйте раз. Якщо він падає — повторні перезапуски — театр. Читайте journalctl -u pveproxy і виправляйте перший рядок помилки.

5) Чи справді відсутній монтаж /etc/pve ламає UI?

Так. Proxmox зберігає ключові конфіги і сертифікатні матеріали під /etc/pve, яке забезпечується pmxcfs. Якщо воно не змонтоване або нездорове — сервіси, що залежать від нього, можуть падати або запускатись з відсутніми файлами.

6) Як часто диск, що заповнений, — справжня причина?

Достатньо часто, щоб бути в перших п’яти перевірках. Заповнений корінь ламає демони, генерацію сертифікатів, логування і іноді postinst‑скрипти пакетів. Це не граніт, але поширене.

7) Я оновив пакети, але не перезавантажував. Чи могло це спричинити відмову 8006?

Так. Post‑install скрипти пакетів можуть перезапустити сервіси негайно. Якщо залежність змінилася (OpenSSL, perl‑модулі, стан конфігураційної файлової системи) — перезапуск може завершитися невдачею навіть без перезавантаження.

8) Якщо втрата кворуму, чи відмовить 8006 у з’єднанні?

Не завжди. Втрата кворуму частіше призводить до невдач при операціях керування або до визнання конфігів як доступних лише для читання. Але це може непрямо зламати шляхи сертифікатів і поведінку pmxcfs, що не дозволить pveproxy запуститися.

9) Чи варто відкривати 8006 в інтернет, щоб «зробити його працездатним»?

Ні. Виправте реальну проблему. Якщо потрібен віддалений доступ — використовуйте VPN, bastion або суворо обмежений allowlist. Виставлення площини керування в інтернет — це шлях до проведення вихідних вихідних у вихідні при розслідуванні інцидентів.

10) Якщо 8006 слухає, але я все одно не можу завантажити UI — що тепер?

Це вже не «connection refused». Перевірте помилки браузера, TLS‑алерти і чи влучаєте ви в правильний IP/DNS. Також підтвердіть, що pvedaemon працює і що хост не під значним ресурсним навантаженням.

Наступні кроки, які варто зробити

Спочатку відновіть сервіс, потім ускладніть повторення цієї ситуації.

1. Зафіксуйте швидкі перевірки: ss -lntp, systemctl status pveproxy, journalctl -u pveproxy, df -h, nft list ruleset. Покладіть їх у свій ранбук саме в цьому порядку.
2. Додайте моніторинг, що ловить справжніх вбивць: використання кореневого файлового простору, використання inode, здоров’я pmxcfs і чи слухає 8006 з зовнішньої точки зору.
3. Не ставтесь до оновлень як до «простих патчів»: плануйте їх, стаджуйте і знімайте before/after diff фаєрволу та мережевого стану. Нудна практика — це те, що працює о 3:00.
4. Для кластерів: розглядайте кворум і з’єднання corosync як частину площини керування. Якщо кластер нестабільний — UI лише симптом, а не хвороба.

Якщо ви нічого іншого не зробите: наступного разу при «Connection refused» перевірте, чи щось слухає на 8006, перш ніж чіпати фаєрвол. Ця звичка зекономить години і врятує від «агресивного» виправлення неправильних речей.