Веб‑інтерфейс Proxmox не відкривається на порті 8006: перезапустіть pveproxy і відновіть доступ

Швидкий план діагностики

Коли порт 8006 недоступний, ви шукаєте вузьке місце, а не збираєте відчуття. Найшвидший шлях — відповісти на три питання в порядку:

1) Хто‑небудь слухає на 8006?

Якщо ніхто не слухає, зазвичай pveproxy зупинився, застряг, не зміг забіндитись або не ініціалізував TLS. Якщо ж хтось слухає, але підключення немає — то це, скоріше за все, питання файрволу/маршрутизації/VRF/інтерфейсу/IP.

2) Якщо pveproxy впав, чому?

Не перезапускайте сліпо сервіс, який падає в циклі — дізнайтесь причину через systemctl і journalctl. Найпоширеніші винуватці:

• Проблеми з сертифікатом/ключем
• Заповнений диск (особливо root)
• Проблеми з кластерною файловою системою (pmxcfs)
• Виснаження дескрипторів файлів або нестача пам’яті
• Конфлікти портів або неправильна адреса для bind

3) Якщо pveproxy запущений, чому браузер не підключається?

Тепер спочатку перевірте локальну доступність (curl з хоста), потім віддалену (з іншого вузла або робочої станції), далі файрвол і мережевий шлях. Веб‑інтерфейс — це звичайний HTTPS на 8006. Ставтеся до нього як до будь‑якої іншої HTTPS служби.

Одна операційна цитата, яка добре витримала час: «Надія — не стратегія.» — Simon Sinek. Це не література з надійності, але має бути в кожному on‑call‑роутіні.

Що таке порт 8006 (і чим він не є)

Веб‑інтерфейс Proxmox VE обслуговується pveproxy — HTTP(S)‑проксі, який спілкується з бекенд‑демонами (pvedaemon, pvestatd та іншими) і читає стан кластера через pmxcfs. Якщо ви втрачаєте UI, а VM продовжують працювати — це нормальна поведінка: гіпервізор і гостьові ОС можуть продовжувати роботу, поки компонент управління падає.

Порт 8006 — це не «Proxmox‑сервер» в цілому. Це площина управління. Ставтесь до неї відповідно. Ви можете відновити її без втручання в робочі VM, якщо уникатимете грубих дій (наприклад, перезавантаження хоста під час перевірки сховища або перереобрання кворуму кластера).

Короткий жарт #1: Коли UI Proxmox падає — це як коли в машині вимикається радіо: двигун ще працює, але раптом кожен в салоні стає інженером зі зберігання даних.

Цікаві факти та історичний контекст (бо контекст рятує від дурних помилок)

• Порт 8006 — це конвенція Proxmox, а не універсальний стандарт. Proxmox обрав його роками раніше, щоби уникнути конфліктів з типово вживаними веб‑портами і щоб одразу було зрозуміло «це Proxmox».
• pveproxy за замовчуванням використовує TLS, навіть у внутрішніх мережах. Це прагматичний вибір безпеки: площини управління атакуються, навіть якщо думають «всередині мережі».
• Кластерна файлова система Proxmox (pmxcfs) — це FUSE у простому просторі користувача, підпирається Corosync. Коли вона працює неправильно, інструменти управління поводяться дивно, тоді як гості залишаються в порядку.
• Історично багато відмов UI — це «опосередковані» збої: заповнений диск, зла синхронізація часу або прострочені сертифікати. UI — місце, де ви помічаєте проблему, але не обов’язково її джерело.
• Systemd змінив операційну гру для сервісів на кшталт pveproxy: справжня причина відмови майже завжди в журналі, а не в невизначеному виводі init‑скрипта.
• Генерація TLS‑сертифікатів у Proxmox — рутина. Платформа розрахована на те, що сертифікати можна замінювати локально; вона орієнтована як на пристрої в лабораторіях, так і на підприємства.
• Uptime VM може вводити в оману. KVM і QEMU байдуже ставляться до того, що pveproxy впав, що добре для навантаження і погано для самовпевненості.
• Відмови 8006 часто самостійно спричинені командою: зачистки, жорстке посилення файрволу або надмірно агресивні правила IPS, які не тестувалися щодо трафіку управління.

Практичні завдання: команди, очікуваний вивід і що вирішувати

Це реальні дії, які я б виконав на хості, що «працює», але має мертвий UI. Кожна задача включає значення виводу та подальші дії. Виконуйте команди від root (або з sudo). Підказки в командних рядках — ілюстративні.

Завдання 1: Підтвердити досяжність хоста і IP

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.20.11/24 fe80::a00:27ff:fe12:3456/64
vmbr0            UP             10.10.20.11/24 fe80::a00:27ff:fe12:3456/64

Значення: У вас є IP, інтерфейси підняті, і ви знаєте, на якій адресі має бути UI.

Рішення: Якщо немає очікуваного IP (або неправильний VLAN), спочатку виправте мережу. Якщо IP в порядку — рухайтесь далі.

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

cr0x@server:~$ ss -lntp | grep ':8006'
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("pveproxy",pid=2143,fd=6))

Значення: pveproxy слухає на всіх IPv4‑адресах.

Рішення: Якщо вивід порожній — pveproxy не слухає. Перейдіть до статусу сервісу та логів. Якщо слухає тільки на 127.0.0.1:8006, то у вас проблема з bind.

Завдання 3: Перевірити локальний HTTPS із хоста

cr0x@server:~$ curl -kI https://127.0.0.1:8006/
HTTP/1.1 200 OK
server: pve-api-daemon/3.0
content-type: text/html; charset=UTF-8
content-length: 1791

Значення: Веб‑сервіс відповідає локально. Невдача в браузері може бути спричинена мережею/файрволом/DNS/маршрутом, а не pveproxy.

Рішення: Якщо локальний curl повертає «connection refused» — фокусуйтеся на pveproxy. Якщо успіх, протестуйте з іншої машини і перевірте файрвол.

Завдання 4: Перевірити статус systemd для pveproxy

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: failed (Result: exit-code) since Wed 2025-12-24 09:12:17 UTC; 2min 8s ago
    Process: 2012 ExecStart=/usr/bin/pveproxy start (code=exited, status=1/FAILURE)
   Main PID: 2012 (code=exited, status=1/FAILURE)

Dec 24 09:12:17 server pveproxy[2012]: can't load certificate '/etc/pve/local/pve-ssl.pem'
Dec 24 09:12:17 server systemd[1]: pveproxy.service: Main process exited, code=exited, status=1/FAILURE
Dec 24 09:12:17 server systemd[1]: pveproxy.service: Failed with result 'exit-code'.

Значення: pveproxy падає через помилку завантаження TLS‑сертифіката.

Рішення: Виправляйте сертифікати (розділ нижче). Якщо статус «active (running)» — переходьте до перевірки файрволу/мережі. Якщо статус «activating» без кінця — перевірте залежності (pmxcfs, pvedaemon) і навантаження на ресурси.

Завдання 5: Прочитати журнал для останньої помилки

cr0x@server:~$ journalctl -u pveproxy -n 100 --no-pager
Dec 24 09:12:17 server pveproxy[2012]: starting server
Dec 24 09:12:17 server pveproxy[2012]: can't load certificate '/etc/pve/local/pve-ssl.pem'
Dec 24 09:12:17 server pveproxy[2012]: Unable to load local private key
Dec 24 09:12:17 server systemd[1]: pveproxy.service: Main process exited, code=exited, status=1/FAILURE

Значення: Лог дає прикладну причину відмови, а не просто «failed».

Рішення: Виправляйте те, що вказано в логах. Не перезапускайте безкінечно сервіс, вдаючи, що це прогрес.

Завдання 6: Підтвердити здоров’я pvedaemon (бекенд API)

cr0x@server:~$ systemctl status pvedaemon --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Wed 2025-12-24 06:01:10 UTC; 3h 13min ago
   Main PID: 1122 (pvedaemon)
      Tasks: 6 (limit: 154000)
     Memory: 62.4M
        CPU: 2min 19s

Значення: Бекенд працює.

Рішення: Якщо pvedaemon впав — перезапустіть його і перевірте журнал; іноді pveproxy падає через неуспішний upstream.

Завдання 7: Підтвердити, що pmxcfs змонтований і відповідає

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

Значення: Кластерна файлова система змонтована в /etc/pve.

Рішення: Якщо її немає, багато інструментів Proxmox зламаються. Потрібно відновити pve-cluster і стан corosync.

Завдання 8: Перевірити місце на диску (root повний — тихий вбивця)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        30G   30G     0 100% /

Значення: Файлова система root повністю заповнена. Сервіси падають дивними способами: не пишуть логи, не записують сертифікати, сокети не створюються.

Рішення: Негайно звільніть місце (логи, старі ядра обережно, кеш). Потім перезапустіть сервіси. Не «просто перезавантажуйте» — перезавантаження з повним root не лікує проблему.

Завдання 9: Перевірити, чи порт не блокується локальними правилами файрволу

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

cr0x@server:~$ pve-firewall localnet
Local network: 10.10.20.0/24

Значення: Файрвол Proxmox увімкнений і має визначену локальну мережу.

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

Завдання 10: Інспектувати iptables/nftables на предмет drop для 8006

cr0x@server:~$ nft list ruleset | grep -n '8006' | head
128: tcp dport 8006 drop

Значення: Існує явний drop на 8006.

Рішення: Видаліть або перекрийте це правило правильно (ідеально — через конфігурацію Proxmox firewall, а не хаотично через CLI). Якщо ви не мали наміру блокувати — знайдіть, хто це зробив.

Завдання 11: Тест віддаленої доступності з іншого хоста (перевірка мережевого шляху)

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

Значення: TCP‑рукопотискання вдале. Якщо браузер все ще падає — дивіться TLS/сертифікати, проксі або клієнтські проблеми.

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

Завдання 12: Перевірити конфлікти портів

cr0x@server:~$ ss -lntp | awk '$4 ~ /:8006$/ {print}'
LISTEN 0 128 0.0.0.0:8006 0.0.0.0:* users:(("nginx",pid=1888,fd=12))

Значення: Інша служба (тут nginx) займає 8006. pveproxy не може забіндитись і падає.

Рішення: Зупиніть або переналаштуйте конфліктний сервіс. У стандартній інсталяції Proxmox володіє 8006. Не сперечайтесь із цим, якщо не полюбляєте біль.

Завдання 13: Перевірити наявність і доступність TLS‑файлів

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

Значення: Файли існують і мають розумні права (читабельні для групи www-data, яку використовує pveproxy).

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

Завдання 14: Перевірити синхронізацію часу (валідність сертифікатів і TLS)

cr0x@server:~$ timedatectl
               Local time: Wed 2025-12-24 09:15:33 UTC
           Universal time: Wed 2025-12-24 09:15:33 UTC
                 RTC time: Wed 2025-12-24 09:15:32
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

Значення: Час не синхронізовано; NTP вимкнено.

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

Перезапуск pveproxy (і залежних сервісів)

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

Мінімальний безпечний перезапуск

Це дія «Потрібен UI назад прямо зараз», коли ви вже знаєте, що це транзисторний крах, а не глибока причина.

cr0x@server:~$ systemctl restart pveproxy
cr0x@server:~$ systemctl is-active pveproxy
active

Значення: Сервіс перезапустився і активний.

Рішення: Негайно перевірте, що він слухає і обслуговує HTTPS, а не просто має статус «active» в systemd.

cr0x@server:~$ ss -lntp | grep ':8006'
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("pveproxy",pid=2299,fd=6))

Перезапуск «площини управління» (важливий порядок)

Якщо підозрюєте глибшу проблему стеку управління — дивний pmxcfs, застряглі сокети, часткові оновлення — перезапускайте релевантні сервіси в розумному порядку. Я віддаю перевагу такій послідовності на одному вузлі:

1. pve-cluster (pmxcfs)
2. pvedaemon
3. pvestatd
4. pveproxy

cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ systemctl restart pvedaemon
cr0x@server:~$ systemctl restart pvestatd
cr0x@server:~$ systemctl restart pveproxy
cr0x@server:~$ systemctl --no-pager --failed
  UNIT          LOAD   ACTIVE SUB    DESCRIPTION
0 loaded units listed.

Значення: За даними systemd, наразі немає впалих юнітів.

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

Коли перезапускати corosync (а коли ні)

В кластері перезапуск corosync може викликати переобрання і тимчасову нестабільність управління. Якщо проблема локалізована на одному вузлі, не починайте з corosync. Спочатку підтвердьте стан mount для /etc/pve. Якщо pmxcfs зламався через застряглий corosync — тоді так, можливо доведеться виправляти corosync, але це вже свідомий крок.

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Wed 2025-12-24 06:01:05 UTC; 3h 18min ago

Рішення: Якщо corosync впав і це вузол кластера, очікуйте ширших симптомів (відсутність кворуму, неможливість оновлення /etc/pve). Розглядайте це як інцидент кластера, а не просто «UI впав».

Глибинні причини: TLS, файрвол, pmxcfs, навантаження та проблеми bind

Коли 8006 недоступний, помилка майже завжди лежить в одній із цих категорій. Відповідь залежить від категорії. Погана новина: з браузера все може виглядати однаково. Хороша новина: Linux дає вам сліди.

TLS/сертифікатні відмови: pveproxy не стартує або клієнти відкидають підключення

Поширені ознаки:

• systemctl status pveproxy показує помилки завантаження сертифікатів
• Браузер видає помилку TLS‑handshake (не просто попередження)
• curl -k не проходить через проблеми handshake

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

cr0x@server:~$ pvecm updatecerts --force
Setting up certificates
done.
Restarting pveproxy and pvedaemon
done.

Значення: Proxmox перегенерував сертифікати і перезапустив ключові сервіси.

Рішення: Якщо у вас використовуються кастомні сертифікати — не затирайте їх з --force без перевірки. Інакше «полагодите UI», але зламаєте довірчі ланцюжки для автоматизації й моніторингу.

Щоб перевірити дати і subject сертифіката:

cr0x@server:~$ openssl x509 -in /etc/pve/local/pve-ssl.pem -noout -subject -dates
subject=CN = server
notBefore=Dec 24 09:10:00 2025 GMT
notAfter=Dec 23 09:10:00 2035 GMT

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

Блокування файрволом: pveproxy в порядку, але до нього ніхто не добирається

Саме тут команди витрачають години, бо «сервіс працює» — так, локально. Мережа все одно може зіпсувати день.

Спочатку перевірте на хості, що він слухає. Потім перевірте, чи доступний він з клієнтської мережі. Якщо блокується — дивіться правила Proxmox firewall і базовий nftables/iptables.

cr0x@server:~$ pve-firewall compile
Compiling firewall ruleset...
done

Значення: Правила файрволу зкомпільовані успішно. Це не означає, що вони коректні; це означає, що синтаксис в порядку.

Рішення: Якщо компіляція падає — виправляйте конфіг. Якщо вона успішна, але блокує вас — дозвольте TCP/8006 явно для вашої мережі управління.

Швидка перевірка падінь під час спроби підключення:

cr0x@server:~$ journalctl -k -n 50 --no-pager | grep -i drop
Dec 24 09:18:04 server kernel: IN=vmbr0 OUT= MAC=... SRC=10.10.30.50 DST=10.10.20.11 LEN=60 ... DPT=8006 ...

Рішення: Якщо бачите kernel drops для 8006 з вашого IP — припиніть звинувачувати pveproxy. Виправляйте шлях файрволу.

pmxcfs і кластерні дивності: /etc/pve — прихована залежність

Якщо /etc/pve не змонтований, управління Proxmox стає моторошним місцем. pveproxy може стартувати, але не читати потрібну конфігурацію, або не знайти сертифікати у /etc/pve/local.

Перевірити стан кластерної файлової системи:

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)
     Active: active (running) since Wed 2025-12-24 06:01:03 UTC; 3h 19min ago

Рішення: Якщо pve-cluster падає — дивіться його журнал. На одновузловій системі без corosync воно все одно може працювати в локальному режимі, але корупція чи заповнений диск можуть його зламати.

Навантаження на ресурси: пам’ять, дескриптори, CPU‑steal

Сервіси управління невеликі, але не магічні. Якщо хост під свапом, у сильному IO‑wait або без FD, pveproxy може стартувати й одразу померти або не приймати з’єднання.

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        60Gi       450Mi       1.2Gi       1.6Gi       620Mi
Swap:           16Gi        15Gi       1.0Gi

Рішення: Якщо swap активно використовується і доступної пам’яті мало — у вас повільна катастрофа. Зменшіть навантаження, зупиніть процеси, що вийшли з-під контролю, розгляньте можливість переміщення VM, після чого перезапустіть сервіси управління.

cr0x@server:~$ ulimit -n
1024

Значення: Поточний ліміт відкритих файлів у сесії низький. Сервіси можуть мати власні ліміти, але якщо система загалом обмежена — з’являться дивні відмови.

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

Проблеми bind‑адреси: pveproxy слухає лише локально або на неправильному інтерфейсі

Іноді pveproxy працює, але забіндиться так, що віддалено підключитися неможливо. Ви побачите це у виводі ss.

cr0x@server:~$ ss -lntp | grep ':8006'
LISTEN 0      4096       127.0.0.1:8006      0.0.0.0:*    users:(("pveproxy",pid=2401,fd=6))

Значення: Слухає лише на loopback. Віддалені клієнти ніколи не підключаться.

Рішення: Шукайте кастомні проксі‑конфіги або змінні оточення для bind. Часто це від забудькуватих тимчасових змін, коли хтось «протестував, прив’язав до localhost і забув». Тимчасові зміни мають дивний план виходу на пенсію: вони ніколи не йдуть у відставку.

DNS і клієнтські проблеми: ваш ноутбук вам бреше

Якщо по IP підключається, а по імені — ні, маєте проблему DNS або split‑horizon. Якщо браузер кешує HSTS або прив’язав сертифікат, можуть виникати клієнтські помилки навіть після лікування сервера. Перевіряйте з нейтрального хоста через IP.

cr0x@server:~$ getent hosts server
10.10.20.11     server

Рішення: Якщо хостнейм резолвиться на неправильний IP — виправляйте DNS/hosts і не гадати.

Три міні‑історії з корпоративного світу (анонімні, правдоподібні і болісно знайомі)

Міні‑історія 1: Відмова через хибне припущення

У них був невеликий кластер Proxmox для внутрішніх інструментів: CI‑раннери, кілька баз даних і «тимчасовий» NFS, який пережив три реорганізації. Одного ранку UI впав на одному вузлі. На чергуванні припустили, що це звичайний глюк pveproxy і перезапустили pveproxy та pvedaemon.

Нічого не змінилося. Вони ескалували до «мережевого питання», бо могли пропінгувати хост, але не вантажити UI. Провели годину, дивлячись на порти комутаторів і переслідуючи VLAN‑привидів. Тим часом VM продовжували працювати, що всіх заспокоїло і зробило інцидент «не терміновим».

Хибне припущення було тонким: «Якщо я можу пропінгувати — UI має працювати». Ping мало що каже про TCP‑доступність, падіння файрволу або про те, чи сервіс слухає на правильному інтерфейсі. Вони не перевірили ss -lntp або curl -kI локально. Також не дивились nftables.

Фактична причина: зміна безпеки, розгорнута автоматизацією, додала правило nftables, що drop‑ило вхідні на 8006 для «не‑адмінських» мереж. Визначення мережі адміністраторів було помилковим на один підмережевий блок. Локальні тести працювали. Віддалені — ні.

Виправлення зайняло п’ять хвилин, коли вони перестали гадати: перевірили listener, підтвердили локальний curl, підтвердили, що TCP віддалено не проходить, знайшли nft drop, виправили localnet/правило, перекомпілювали. Написали постмортем, де не звинуватили файрвол — винним стало припущення.

Міні‑історія 2: Оптимізація, яка обернулась проти них

Інша команда вирішила зробити «чистіший» доступ до управління. Поставили реверс‑проксі перед Proxmox, щоб уніфікувати доступ під одним доменом і отримати кращі сертифікати. Мета була правомірна.

А далі оптимізація: ввели агресивні таймаути і обмеження з’єднань на проксі, бо «UI — це лише дашборд, не критичне». Працювало, поки вузол не став завантаженим і API‑виклики не почали виконуватись довше. Проксі почав обривати з’єднання посередині, через що браузери поводились так, ніби UI впав.

Паралельно звузили набори шифрів. Деякі старі автоматичні скрипти (curl у старих build‑агентах) перестали автентифікуватись. Люди «виправляли» це тим, що обходили проксі і йшли напряму на :8006, створивши спліт‑брейн патерн доступу без документування.

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

Proxmox не був нестабільним. Їхня оптимізація змінила режим відмов з «вузол повільний» на «доступ до управління непослідовний». Це гірше. Вони відкотили обмеження з’єднань, налаштували таймаути відповідно до реальності і стандартизували один шлях доступу з health‑чеком, що робить GET на / на 8006 і перевіряє 200.

Міні‑історія 3: Нудна але правильна практика, що врятувала день

Ще одна організація працювала дуже консервативно: окремий VLAN для управління, задокументовані IP і звичка тестувати доступність UI з моніторингової машини кожну хвилину. Нічого особливого. Просто «чи відповідає HTTPS на 8006».

У них також був нудний рукбук, що починався з: перевірити listener, перевірити статус systemd, переглянути журнал, перевірити диск, перевірити файрвол. Здавалося, написано втомленим SRE у вівторок. Саме такі рукбуки й потрібні.

Одного дня моніторинг сповістив: «Proxmox UI впав на node3». На чергуванні через SSH (який працював іншим шляхом доступу) виконали рукбук. df -h / показав root на 100%. Journald ще логував, але сервіси не могли писати стан і TLS‑оновлення не проходили.

Вони звільнили місце, обрізавши старі логи і видаливши кілька непотрібних ISO з неправильної директорії. Потім перезапустили pveproxy і підтвердили, що curl -kI видає 200. UI повернувся за 15 хвилин без ребута і без переривання VM.

Практика, що їх врятувала, була нудною: моніторити площину управління окремо від стану VM та мати рукбук, що не починається з молитви.

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

Це патерни, які ви бачитимете регулярно. Симптоми перекриваються. Виправлення — ні.

1) Браузер одразу показує «connection refused»

• Симптом: Миттєвий відмова; немає TLS‑попередження; немає таймауту.
• Корінь: Ніхто не слухає на 8006, або порт відкидається з REJECT.
• Виправлення: Виконайте ss -lntp | grep :8006. Якщо порожньо — перезапустіть pveproxy і перевірте журнал. Якщо слухає — перевірте правила файрволу і віддалений шлях.

2) Браузер таймаутить (крутиться назавжди)

• Симптом: Довге очікування; зрештою таймаут.
• Корінь: DROP файрволу на шляху, проблема маршруту, неправильний VLAN або асиметрія; іноді хост настільки перевантажений, що черга accept не обробляється.
• Виправлення: Тестуйте TCP через nc -vz з клієнта, перевіряйте логи nftables/drop, валідність маршрутів. Якщо навантаження хоста екстремальне — зменшіть навантаження і повторіть.

3) UI завантажується, але автентифікація не проходить або задачі зависають

• Симптом: Сторінка входу працює, але операції падіння або ви бачите «501»/«proxy error»‑подібні повідомлення.
• Корінь: Проблеми бекенд‑демонів (pvedaemon), затримки pmxcfs, проблеми кворуму кластера.
• Виправлення: Перевірте systemctl status pvedaemon pve-cluster, дивіться журнали, перевіряйте здоров’я кластера. Перезапустіть сервіси управління у правильному порядку.

4) Після «очищення» pveproxy не стартує (помилки сертифікатів)

• Симптом: Журнал показує відсутній або нечитабельний /etc/pve/local/pve-ssl.pem або ключ.
• Корінь: Хтось видалив файли під /etc/pve, або права змінились, або pmxcfs не змонтований.
• Виправлення: Переконайтесь, що /etc/pve змонтовано; перегенеруйте сертифікати через pvecm updatecerts --force (після підтвердження, що заміна прийнятна).

5) UI зламався одразу після ввімкнення Proxmox firewall

• Симптом: Локальний curl працює, віддалений — ні; зміни співпадають з увімкненням файрволу.
• Корінь: Відсутнє правило allow для TCP/8006 від адмін‑підмережі або некоректний localnet.
• Виправлення: Виправте localnet, додайте явний allow для 8006, перекомпілюйте і перезавантажте файрвол.

6) UI зламався одразу після встановлення nginx/apache «для іншого»

• Симптом: pveproxy не може забіндитись; логи згадують address already in use.
• Корінь: Інша служба захопила порт 8006 або зробила wildcard bind на IP управління.
• Виправлення: Знайдіть слушач через ss -lntp, перемістіть іншу службу, перезапустіть pveproxy.

7) UI показує помилки TLS handshake після зміни системного часу

• Симптом: Клієнтські помилки на кшталт «certificate not yet valid» або раптові TLS‑помилки.
• Корінь: Дрейф часу або вимкнений NTP; дати сертифіката не відповідають реальності.
• Виправлення: Налаштуйте NTP/синхронізацію часу, після потреби перегенеруйте сертифікати і перезапустіть pveproxy.

Короткий жарт #2: Перезапуск випадкових сервісів без читання логів — як перезавантажити тостер, щоб полагодити Wi‑Fi: іноді приємно, але рідко ефективно.

Чек‑лісти / покроковий план

Чек‑ліст A: «Мені потрібен UI назад за 10 хвилин»

1. Підключіться по SSH до вузла (бажано через management‑мережу).
2. Перевірте listener: ss -lntp | grep :8006.
3. Якщо не слухає: systemctl status pveproxy і journalctl -u pveproxy -n 100.
4. Виправте очевидне (повний диск, відсутній сертифікат, конфлікт порту).
5. Перезапустіть у порядку: systemctl restart pve-cluster pvedaemon pvestatd pveproxy.
6. Перевірте локально: curl -kI https://127.0.0.1:8006/.
7. Перевірте віддалено: nc -vz <node-ip> 8006 з клієнтської машини.

Чек‑ліст B: «Знайти корінь проблеми, щоб це не повторилось»

1. Витягніть час останнього завантаження і хронологію рестартів.
2. Проаналізуйте journald для pveproxy і pve-cluster помилок у вікні інциденту.
3. Перевірте тренди використання диска; знайдіть, що заповнило root (логи, бекапи, ISO у невірній папці).
4. Валідуйте налаштування синхронізації часу і історію дрейфу.
5. Аудит змін файрволу: конфіги Proxmox firewall і диф‑правил nftables.
6. Підтвердьте підхід до керування сертифікатами: самопідписані чи централізована CA, практика ротації.
7. Додайте моніторинг, що перевіряє HTTPS 8006 з тієї ж мережі, з якої працюють люди.

Чек‑ліст C: «Кластер: не робіть більший інцидент»

1. Перед втручанням у corosync оцініть: проблема локальна чи кластерна.
2. Перевірте кворум з іншого, здорового вузла, якщо можливо.
3. Якщо /etc/pve пошкоджено на вузлі — розглядайте це як проблему стану кластера, а не просто UI.
4. Уникайте масових перезавантажень вузлів «щоб бути в безпеці». Саме так о 2‑й ночі дізнаються, що таке кворум.

ЧАСТІ ПИТАННЯ

1) Який сервіс фактично подає веб‑інтерфейс Proxmox?

pveproxy. Він слухає TCP/8006 і проксує API‑запити до бекенд‑демонів на кшталт pvedaemon.

2) Якщо я перезапущу pveproxy, чи зупиняться запущені VM?

Ні. Перезапуск сервісів управління не зупиняє QEMU/KVM гостей. Він може тимчасово переривати управлінські задачі (консолі, API‑виклики).

3) UI впав, але SSH працює. Що це означає?

Це означає, що хост живий і досяжний, і ви можете розбиратися локально. Це не означає, що файрвол пропускає 8006 або що pveproxy слухає.

4) Як визначити, файрвол чи сервіс винні?

Перевірте локально спочатку: curl -kI https://127.0.0.1:8006/. Якщо локально працює, але віддалено ні — підозрюйте файрвол/маршрутизацію. Якщо локально не працює — підозрюйте pveproxy або його залежності.

5) Чи можна перемістити UI на інший порт?

Можна, але, ймовірно, не варто. Proxmox багато де передбачає 8006 в операційних звичках і інструментах. Якщо змінюєте, робіть це з добре протестованим реверс‑проксі і зберігайте 8006 доступним у мережі управління.

6) Чому pveproxy потребує /etc/pve?

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

7) Я перегенерував сертифікати і автоматизація зламалась. Що сталося?

Ваша автоматизація, ймовірно, прив’язана до старого відбитка сертифіката або довіряє певному ланцюжку. Перегенерація змінює це. Вирішіть стратегію сертифікації: або консистентно довіряти самопідписаному CA Proxmox, або використовувати централізований підхід до сертифікатів і документувати його.

8) Сервіс «active (running)», але я все ще не можу підключитися. Чому?

Бо «active» не означає «досяжний». Він може слухати лише на localhost, бути заблокованим файрволом або слухати лише IPv6, тоді як ви пробуєте IPv4 (або навпаки). Перевірте ss -lntp і мережеві тести.

9) Чи варто перезавантажувати хост, щоб полагодити UI?

Ребут — крайній захід. Він може допомогти, якщо система сильно застрягла, але також може погіршити кластерний інцидент, перервати операції зі сховищем і сховати реальну причину. Спочатку зберіть логи.

10) Якщо порт 8006 відкритий, але UI дуже повільний — що робити?

Зазвичай це навантаження, IO‑wait, затримки pmxcfs або конкуренція бекенду. Перевірте пам’ять і swap, затримки диска і journalctl на предмет timeouts. Повільність не рівнозначна падінню, але часто має спільний корінь: перевантажений хост.

Висновок: наступні кроки, щоб уникнути цього

Коли веб‑інтерфейс Proxmox на 8006 зникає, найшвидша перемога — дисциплінована триаж: перевірте listener, валідуйте локальний HTTPS, читайте журнал, і лише потім вирішуйте — лагодити pveproxy, його залежності чи мережевий шлях. Перезапуск pveproxy часто правильний крок. Перезапуск без розуму — як перетворити маленький інцидент у заплутаний.

Зробіть наступне:

• Додайте моніторинг, що перевіряє https://<mgmt-ip>:8006/ з тієї ж мережі, якою користуються люди.
• Тримайте запас вільного місця на root. «Майже повний» root — це відкладена відмова з паперами.
• Визначте політику сертифікації (самопідписані чи централізовані) і дотримуйтесь її.
• Ставтесь до змін файрволу як до продакшн‑коду: рев’ю, тестування і план відкату.
• Майте короткий рукбук: ss → systemctl → journalctl → df → перевірки файрволу. Повторюваність краще за героїзм.