pveproxy.service у Proxmox не запускається: 7 поширених причин і правильний порядок виправлення

Швидкий план діагностики (робіть це насамперед)

Ваша мета — не «перезапускати службу доти, поки не запуститься». Ваша мета — визначити вузьке місце за менш ніж п’ять хвилин:
чи це конфігурація, файловий простір, TLS, залежні сервіси чи стан кластера?

Хвилина 0–1: Лише веб‑інтерфейс, чи вузол справді хворий?

• Підтвердіть, що можете зайти по SSH на хост.
• Перевірте, чи працюють ВМ (не робіть припущень; перевіряйте).
• Перевірте, чи слухає локально порт 8006.

Хвилина 1–2: Прочитайте реальну причину збою

• systemctl status pveproxy -l для основного рядка помилки.
• journalctl -u pveproxy -b --no-pager для повного контексту.

Хвилина 2–3: Швидкі виключення, що вирішують половину інцидентів

• Заповнений диск: df -h і df -i (обидва мають значення).
• Зсув часу: timedatectl (TLS не любить подорожей у часі).
• Перевірка імені хоста/IP: hostname -f, getent hosts $(hostname -f).

Хвилина 3–5: Залежності та файловий простір кластера

• Чи запущений pve-cluster? Чи відповідає /etc/pve?
• Чи запущений pvedaemon? Він часто падає з тієї ж базової причини.
• Якщо це кластер: перевірте кворум/стан corosync перед тим, як «виправляти» не ту річ.

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

Цікаві факти та контекст (чому це ламається саме так)

• Факт 1: pveproxy — це служба на Perl, яка термінує HTTPS для веб‑інтерфейсу Proxmox на порті 8006, і вона дуже прискіплива до сертифікатів та прав доступу до файлів.
• Факт 2: Конфігурація кластера Proxmox зберігається в /etc/pve, за підтримки pmxcfs (FUSE‑базований розподілений файловий шар). Якщо /etc/pve «зависає», багато сервісів починають вести себе дивно.
• Факт 3: Навіть на одновузловому «кластері» (так, таке буває) pmxcfs існує. Люди це забувають і неправильно діагностують як «тільки веб‑сервіс».
• Факт 4: Помилки TLS особливо часті після зміни імені хоста, бо Proxmox виписує сертифікати вузла, прив’язані до цієї ідентичності.
• Факт 5: На Debian‑системах «заповнений диск» може проявлятися як відмова записати сертифікат, PID‑файл або лог—тому видима помилка може бути вторинною ознакою.
• Факт 6: Проблеми з кворумом corosync не завжди зупиняють навантаження. Вони часто спочатку зупиняють операції plane‑керування, що робить простої більш болючими для людей, ніж для робочих навантажень.
• Факт 7: Proxmox навмисно централізує багато налаштувань у /etc/pve, щоб вузли кластера конвергувалися. Це зручно для операцій—доки сховище конфігів доступне.
• Факт 8: Падіння порту 8006 не означає «Proxmox впав». У реальних інцидентах ВМ продовжують обслуговувати трафік, тоді як люди панікують через відсутність UI.
• Факт 9: Багато подій «service failed» спричинені зовнішнім фактором: DNS, час, файловий простір чи залежність. Звинувачувати pveproxy — як звинувачувати датчик диму в сигналі про пожежу.

Правильний порядок виправлень: припиніть гадання, почніть звужувати

Ось упорядкована послідовність, яка мінімізує простої та уникне побічної шкоди. Дотримуйтеся її, навіть якщо ви «вже знаєте»,
що сталося. Ви часто помиляєтесь, а логи — не.

1. Стабілізуйте доступ: зайдіть по SSH, переконайтеся, що ви на правильному вузлі, підтвердіть, що робочі навантаження в порядку.
2. Прочитайте причину збою: systemctl status і journalctl. Не перезапускайте ще.
3. Виключіть «необов’язкові помилки»: заповнений диск, вичерпано inode, зсув часу, невідповідність DNS/hostname.
4. Перевірте стан файлового шару кластера: pve-cluster, відгук /etc/pve, FUSE‑монтування.
5. Перевірте сертифікати та ключі: наявність файлів, права, термін дії та чи не змінилася ідентичність вузла.
6. Перевірте конфлікти прив’язки порту: чи хтось інший займає 8006 або лишилися старі процеси.
7. Лише потім перезапускайте служби: робіть це в порядку залежностей і стежте за логами під час виконання.

Ось цитата, що тримає вас чесним. Ідея Вернера Вогельса (CTO AWS) добре підходить для операцій:
Усе ламається постійно; проєктуйте й експлуатуйте так, ніби відмова — нормальне явище. — Вернер Вогельс (парафраз)

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

7 поширених причин pveproxy.service failed (із правильним виправленням)

Причина 1: Заповнений диск (або вичерпано inode) ламає plane керування

Якщо кореневий том заповнений, pveproxy не може записувати логи, PID‑файли або тимчасові файли. Якщо inode вичерпані, може бути «вільне місце»,
але ви все одно не зможете створювати файли. Обидва випадки дають помилки, що нагадують TLS, проблеми з правами або випадкові збої сервісів.

Порядок виправлення: звільніть місце безпечно, потім перезапустіть служби. Не видаляйте випадкові файли в /etc/pve або /var/lib/pve-cluster.

• Очищайте кеші apt, старі ядра (обережно), старі логи і невдалі бекапи.
• Перевіряйте /var/log, /var/lib/vz, /rpool (ZFS) та будь‑які підключені цілі для резервних копій.

Причина 2: Проблеми з pmxcfs / pve-cluster (завислий /etc/pve)

Якщо /etc/pve повільний або застряг, сервіси, що читають конфіг з нього, поводяться погано. Іноді вони зависають; іноді виходять.
Класична ознака: команди на кшталт ls /etc/pve зависають або pvecm status виконується вічно.

Порядок виправлення: перевірте pve-cluster і стан corosync/кворуму (якщо в кластері), потім акуратно перезапускайте кластерні сервіси.

Причина 3: Проблеми з сертифікатом/ключем (прострочені, відсутні, неправильні права або невідповідність імені хоста)

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

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

Причина 4: Розходження ідентичності вузла та резолюція імен

Proxmox чутливий до ідентичності вузла, бо це впливає на членство в кластері, імена в сертифікатах та очікування API. Непомітна зміна імені хоста
(або збій DNS) може спричинити каскад «pveproxy failed», бо інші компоненти відмовляються працювати з невідповідною ідентичністю.

Порядок виправлення: відлагодьте /etc/hosts / DNS перш за все, потім сертифікати, потім служби.

Причина 5: Конфлікт прив’язки порту 8006 або застарілий процес

Іноді pveproxy не може прив’язатися до 8006, бо інший процес його вже використовує — часто неправильно налаштований зворотний проксі, тестовий сервіс
або попередній екземпляр, що не вийшов чисто.

Порядок виправлення: ідентифікуйте процес, що займає порт, зупиніть або переконфігуруйте його, потім запустіть pveproxy.

Причина 6: Зламаний стан пакетів або неповні оновлення

Напівзавершене оновлення може залишити модулі Perl, бібліотеки або файли конфігурації в неконсистентному стані. Симптом: pveproxy падає з помилками завантаження модулів
або запускається, але кидає runtime‑виключення.

Порядок виправлення: перевірте стан пакетів, виправте проблеми dpkg, перевстановіть релевантні пакети за потреби, і лише потім перезапускайте.

Причина 7: Зсув часу та дивні ефекти TLS/куків

Якщо час стрибнув, сертифікати можуть виглядати «не чинними ще» або «простроченими», сесії поводяться дивно, і браузери показують помилки, які виглядають як баги UI.
Проблеми з NTP також часто збігаються з подіями живлення або зсувами часу на віртуалізаційному хості.

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

Жарт №2: Зсув часу — єдина помилка, яка може зробити ваш сертифікат «простроченим у майбутньому». Вітаємо, ви винайшли подорож у часі — на жаль, для TLS.

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

Ось завдання, які я насправді виконую. Не тому, що вони модні, а тому, що швидко скорочують поле пошуку.
Кожне завдання містить: команду(и), що означає вивід, і яке рішення прийняти далі.

Завдання 1: Підтвердити стан служби і зафіксувати основний рядок помилки

cr0x@server:~$ systemctl status pveproxy -l
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: failed (Result: exit-code) since Mon 2025-12-25 10:31:14 UTC; 2min 3s ago
    Process: 1234 ExecStart=/usr/bin/pveproxy start (code=exited, status=255/EXCEPTION)
   Main PID: 1234 (code=exited, status=255/EXCEPTION)

Dec 25 10:31:14 pve1 pveproxy[1234]: starting server
Dec 25 10:31:14 pve1 pveproxy[1234]: can't open certificate '/etc/pve/local/pve-ssl.pem': No such file or directory
Dec 25 10:31:14 pve1 systemd[1]: pveproxy.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 25 10:31:14 pve1 systemd[1]: pveproxy.service: Failed with result 'exit-code'.

Значення: Це не «UI повільний». Це жорстка помилка при старті. Ключовий рядок — помилка з шляхом до файлу.
Рішення: не чіпайте порти чи правила брандмауера поки що. Йдіть безпосередньо до перевірки наявності сертифікатів/ключів і стану /etc/pve.

Завдання 2: Прочитати повний журнал pveproxy для цього завантаження

cr0x@server:~$ journalctl -u pveproxy -b --no-pager -n 200
Dec 25 10:31:14 pve1 pveproxy[1234]: starting server
Dec 25 10:31:14 pve1 pveproxy[1234]: can't open certificate '/etc/pve/local/pve-ssl.pem': No such file or directory
Dec 25 10:31:14 pve1 systemd[1]: pveproxy.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 25 10:31:14 pve1 systemd[1]: pveproxy.service: Failed with result 'exit-code'.

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

Завдання 3: Перевірити, чи що‑небудь слухає на порту 8006 локально

cr0x@server:~$ ss -ltnp | grep -E ':8006\s'

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

Завдання 4: Визначити процес, якщо 8006 зайнятий

cr0x@server:~$ ss -ltnp | grep -E ':8006\s'
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("nginx",pid=2200,fd=12))

Значення: Nginx на 8006. Це майже завжди неправильно на вузлі Proxmox, хіба ви свідомо не перемістили UI.
Рішення: зупиніть або переналаштуйте nginx; звільніть 8006; потім запустіть pveproxy.

Завдання 5: Перевірити вільне місце і доступність inode (обидва)

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

cr0x@server:~$ df -i /
Filesystem     Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2     1835008 250000 1585008   14% /

Значення: Місця 100%. Inode — ок. Це може заважати старту сервісів.
Рішення: звільніть місце перед будь‑якими діями. Перезапуск не допоможе; може лише погіршити.

Завдання 6: Знайти найвідоміших споживачів швидко (без сліпого видалення)

cr0x@server:~$ du -xhd1 /var | sort -h
1.2G    /var/cache
2.8G    /var/log
14G     /var/lib
18G     /var

Значення: Найбільше місця займає /var/lib (часто образи, бекапи або база кластера) та логи.
Рішення: перевірте /var/log на шалений ріст; очистіть кеш apt; перемістіть або видаліть старі резервні копії свідомо.

Завдання 7: Переглянути логи на предмет вибухового зростання і безпечно обрізати

cr0x@server:~$ ls -lh /var/log | tail -n 10
-rw-r----- 1 root adm  12G Dec 25 10:20 syslog
-rw-r----- 1 root adm 1.1G Dec 25 10:20 daemon.log

cr0x@server:~$ sudo truncate -s 0 /var/log/syslog
cr0x@server:~$ sudo systemctl restart rsyslog

Значення: Великий syslog може заповнити корінь. Обрізання залишає дескриптор файлу цілим (корисно, коли демон тримає його відкритим).
Рішення: після звільнення місця перезапустіть pveproxy і його залежності; потім виправляйте джерело спаму в логах.

Завдання 8: Переконатися, що /etc/pve змонтований і відповідає (здоров’я pmxcfs)

cr0x@server:~$ mount | grep -E ' on /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)

cr0x@server:~$ timeout 2 ls -la /etc/pve
total 0
drwxr-xr-x 2 root www-data 0 Dec 25 10:25 local
drwxr-xr-x 2 root www-data 0 Dec 25 10:25 nodes
-rw-r----- 1 root www-data 0 Dec 25 10:25 .members

Значення: FUSE‑монтування є і директорія відповідає за 2 секунди.
Рішення: якщо це зависає або тайм‑аутиться — не гонись за сертифікатами; спочатку лагодьте pve-cluster / corosync.

Завдання 9: Перевірити pve-cluster і corosync/кворум (для кластерів)

cr0x@server:~$ systemctl status pve-cluster -l
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Mon 2025-12-25 10:05:01 UTC; 28min ago

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

Quorum information
------------------
Date:             Mon Dec 25 10:33:01 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.7a
Quorate:          Yes

Значення: Файловий шар кластера працює, кворум є. Добре — проблема, ймовірно, локальна (диск, TLS, конфлікт порту, пакети).
Рішення: переходьте до перевірок сертифікатів та ідентичності вузла для pveproxy.

Завдання 10: Перевірити ідентичність вузла та резолюцію імен

cr0x@server:~$ hostnamectl --static
pve1

cr0x@server:~$ hostname -f
pve1.example.internal

cr0x@server:~$ getent hosts $(hostname -f)
10.10.10.11     pve1.example.internal pve1

Значення: Ім’я хоста резольвиться в IP. Якщо це нічого не повертає або неправильний IP — компоненти Proxmox можуть поводитись дивно.
Рішення: виправте DNS або /etc/hosts спочатку. Не регенеруйте сертифікати поки ідентичність не стане коректною.

Завдання 11: Перевірити синхронізацію часу і чи час взагалі правдоподібний

cr0x@server:~$ timedatectl
               Local time: Mon 2025-12-25 10:33:40 UTC
           Universal time: Mon 2025-12-25 10:33:40 UTC
                 RTC time: Mon 2025-12-25 10:33:39
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Час синхронізований. Якщо ні — браузери і TLS вас покарають.
Рішення: якщо час невірний, виправте NTP першочергово, потім повторіть спробу запустити pveproxy. Не ганяйтесь за уявним простроченням сертифікатів.

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

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

Значення: Файли є. Права показують root і групу www-data, що читає; типово для веб‑компонентів.
Рішення: якщо відсутні — треба регенерувати (після підтвердження здоров’я /etc/pve і коректності імені хоста).

Завдання 13: Перевірити дати дійсності сертифіката і subject (швидка санітарна перевірка)

cr0x@server:~$ openssl x509 -in /etc/pve/local/pve-ssl.pem -noout -dates -subject
notBefore=Dec 25 10:25:01 2025 GMT
notAfter=Dec 24 10:25:01 2035 GMT
subject=CN = pve1.example.internal

Значення: Сертифікат дійсний у часовому інтервалі і пов’язаний з очікуваним CN.
Рішення: якщо CN неправильний або дати дивні — виправте hostname/час і регенеруйте сертифікати.

Завдання 14: Регенерувати сертифікати Proxmox (лише коли ідентичність і /etc/pve коректні)

cr0x@server:~$ pvecm updatecerts --force
updating certificate for node pve1
generating SSL certificate... done

cr0x@server:~$ systemctl restart pveproxy
cr0x@server:~$ systemctl status pveproxy -l
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Mon 2025-12-25 10:35:12 UTC; 2s ago

Значення: Регенерація сертифікатів вдалася і проксі тепер працює.
Рішення: перевірте доступ локально, потім віддалено; якщо віддалено не працює — досліджуйте брандмауер/балансувальник/реверс‑проксі.

Завдання 15: Підтвердити, що локальний UI відповідає (обхід DNS та зовнішньої мережі)

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

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

Завдання 16: Перевірити, чи pvedaemon здоровий (він часто має ту саму кореневу причину)

cr0x@server:~$ systemctl status pvedaemon -l
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Mon 2025-12-25 10:05:03 UTC; 30min ago

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

Завдання 17: Перевірити наявність проблем dpkg/apt після оновлень

cr0x@server:~$ dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 pve-manager  Proxmox VE virtualization management suite

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

Завдання 18: Відновити конфігурацію пакетів і перезапустити чисто

cr0x@server:~$ sudo dpkg --configure -a
Setting up pve-manager (8.2.2) ...
Processing triggers for man-db (2.11.2-2) ...

cr0x@server:~$ sudo apt-get -f install
Reading package lists... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

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

Значення: Ви відновили консистентний стан пакетів.
Рішення: якщо помилки лишаються — повертайтесь до логів; тепер логи надійні і не є артефактом напіввстановленого коду.

Три короткі історії з реальних інцидентів

Міні‑історія 1: Інцидент через хибне припущення (DNS «не може бути ним»)

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

Вузол був доступний по SSH, ВМ працювали, але pveproxy не стартував. Логи згадували сертифікати, що ще більше підкріпило
версію TLS/веб. Вони регенерували сертифікати. Покращення не сталося. Вони перевстановили pve-manager.
Все ще мертво. Попри це інцидент перетворився на двогодинний простій plane‑керування для цього вузла з кількома невдалими «виправленнями», які ускладнили відкат.

Насправді корінь був банальний: запис DNS для FQDN вузла оновили під час проєкту перенумерації IP, але один внутрішній резолвер все ще повертав стару адресу.
На Proxmox вузлі getent hosts $(hostname -f) повертав несподіваний IP. Деякі компоненти вважали, що вони мають одну ідентичність; інші — іншу.

Після узгодження резолюції імен (і перевірки, що /etc/hosts відповідає реальності) сертифікати регенерували ще раз і pveproxy запустився одразу.

Урок не в тому, що «DNS завжди винен». Урок — в тому, що перевірка ідентичності має бути у перші п’ять хвилин. Якщо не підтвердити припущення на початку, решта інциденту
витрачатиметься на лікування симптомів, які ви самі створили.

Міні‑історія 2: Оптимізація, яка відплатилася (зберігання логів і заповнений корінь)

Інше середовище «покращувало» гігієну операцій. Хтось вирішив збільшити зберігання логів на вузлах Proxmox, бо «нам ніколи не вистачає історії під час інцидентів». Благі наміри.

Замість того, щоб продумати навантаження, вони відключили ротацію для кількох шумних підсистем і збільшили розміри журналу. Це працювало, доки сплеск затримок сховища не викликав
повторні повідомлення про перепідключення iSCSI на кількох вузлах. Рівень логів виріс із «балакучого» до «водоспаду», і кореневі томи наповнилися за ніч.

Коли / заповнився, pveproxy не зміг стартувати після перезавантаження, бо не міг записати потрібні файли. Команда ганялася за TLS і проблемами з пакетами, бо видимі помилки згадували сертифікати і файлові операції.
Вони не помилялися — ці операції падали. Просто вони не були першопричиною.

Виправлення було простим: звільнити місце, перезапустити служби. Довгострокове виправлення вимагало дисципліни: політика ротації логів з припущенням пікового навантаження, плюс моніторинг диску та inode з алертами до 90–95% використання, а не при 100%.

Оптимізація відплатилася, бо змінила режим відмови: з «нам не вистачає контексту» до «ми втратили plane керування». У операціях найдорожчі проблеми часто походять від добрих намірів, які не пройшли стрес‑тест.

Міні‑історія 3: Нудна, але правильна практика врятувала день (перезапуски в порядку залежностей і збереження доказів)

Фінансова команда працювала під суворим контролем змін. Їхні руни були не помпезні. Вони не були «інноваційними».
Вони були правильними і відпрацьованими.

Під час робіт з електропостачання один вузол повернувся з pveproxy, що не стартував. Інженер на виклику не перезавантажив вдруге.
Він не перевстановлював пакети. Не регенерував сертифікати з автопілоту. Він дотримався рукаву: зафіксував systemctl status,
journalctl, перевірив диск, час, відгук /etc/pve, потім конфлікти портів.

Вони виявили, що /etc/pve змонтований, але іноді зависав через застряглий стан pve-cluster після відключення живлення.
Кластер був кворумний, але локальний процес файлового шару вузла був незадоволений. Перезапуск у неправильному порядку спричинив би «флап» вузла між пів‑доступними станами.

Вони перезапустили pve-cluster коректно, перевірили відгук /etc/pve, потім перезапустили pvedaemon, потім pveproxy.
UI повернувся, інцидент закінчився та наявний слід доказів зробив постмортем простим.

Нічого героїчного не сталося. Ось у чому суть. Нудна практика — виправляти залежності першими і зберігати докази — зберегла час і не дозволила «виправленню» стати вторинним інцидентом.

Поширені помилки: симптом → корінна причина → виправлення

1) «8006 таймаутиться» → Ви припускаєте брандмауер → Насправді pveproxy не слухає

Симптом: Браузер не може під’єднатися до https://node:8006.

Корінь: pveproxy вимкнений; порт не прив’язано.

Виправлення: виконайте ss -ltnp | grep :8006. Якщо порожньо, прочитайте journalctl -u pveproxy і виправте реальну причину старту.

2) «pveproxy падає з помилкою сертифіката» → Ви одразу регенеруєте сертифікати → Насправді /etc/pve завис

Симптом: Помилки про відсутній або недоступний /etc/pve/local/pve-ssl.pem.

Корінь: pmxcfs нездоровий; /etc/pve недоступний, тому файли «зникають».

Виправлення: перевірте mount | grep /etc/pve і timeout 2 ls /etc/pve; спочатку лагодьте pve-cluster.

3) «UI порожній» → Ви звинувачуєте кеш браузера → Насправді час вузла неправильний

Симптом: TLS‑попередження, дивні сесії, петлі входу.

Корінь: Зсув годинника; перевірки валідності TLS не проходять і куки поводяться дивно.

Виправлення: timedatectl; відновіть NTP; потім перезапустіть pveproxy, якщо потрібно.

4) «Служба не стартує після оновлення» → Ви перевстановлюєте випадкові пакети → dpkg напівсконфігурований

Симптом: Миттєві збої при старті, відсутні модулі, неконсистентна поведінка після оновлення.

Корінь: Часткове оновлення або перервано конфігурацію dpkg.

Виправлення: dpkg --audit, потім dpkg --configure -a і apt-get -f install.

5) «pveproxy каже address in use» → Ви вбиваєте випадкові PID → Інша служба навмисно прив’язана

Симптом: Помилка прив’язки до 8006.

Корінь: Реверс‑проксі або тестовий сервіс прив’язаний на 8006.

Виправлення: ідентифікуйте з ss -ltnp, поміняйте порт того сервісу або поверніть Proxmox на 8006, якщо немає вагомих причин інакше.

6) «pveproxy failed» → Ви перезавантажуєте → Кореневий файловий простір заповнений і перезавантаження нічого не звільнило

Симптом: Служба падає при кожному старті; логи скаржаться на запис файлів.

Корінь: Заповнений диск/вичерпано inode.

Виправлення: df -h і df -i, потім безпечно видаліть/обріжте файли і налаштуйте моніторинг.

7) «Вчора працювало» → Ви ігноруєте зміну імені хоста → Сертифікати і ідентичність кластера не сходяться

Симптом: Несумісність CN у сертифікаті, помилки UI, несумісне іменування вузлів.

Корінь: Зміна hostname/FQDN без оновлення /etc/hosts, DNS і сертифікатів/конфігурацій кластера.

Виправлення: спочатку виправте резолюцію імен, потім pvecm updatecerts --force, потім перезапустіть pveproxy.

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

Чеклист A: Тріаж у перші 10 хвилин (одновузловий або кластер)

1. Підключіться по SSH. Переконайтеся, що ви на правильному вузлі: hostname, ip a.
2. Зберіть докази:
   • systemctl status pveproxy -l
   • journalctl -u pveproxy -b --no-pager -n 200
3. Перевірте, чи слухає: ss -ltnp | grep :8006.
4. Перевірте простір і inode: df -h, df -i.
5. Перевірте час: timedatectl.
6. Перевірте ідентичність: hostname -f, getent hosts $(hostname -f).
7. Перевірте файловий шар кластера: mount | grep /etc/pve, timeout 2 ls /etc/pve.
8. Якщо це кластер: pvecm status і systemctl status corosync.
9. Лише після вищевказаного: перезапустіть залежності, потім pveproxy.

Чеклист B: Безпечний порядок перезапуску (коли підозрюєте проблеми із залежностями)

1. Якщо /etc/pve завис: спочатку лагодьте pve-cluster.
2. Порядок перезапуску (типово): pve-cluster → pvedaemon → pveproxy.
3. Підтверджуйте кожен крок за допомогою systemctl is-active і негайно перевіряйте логи у разі падіння.

Чеклист C: Відновлення сертифікатів без самостійно створених проблем

1. Підтвердіть, що hostname і FQDN резольвяться коректно (hostname -f, getent hosts).
2. Підтвердіть правильність часу (timedatectl).
3. Підтвердіть, що /etc/pve відповідає (немає зависань).
4. Перевірте існуючі файли сертифіката/ключа і права доступу.
5. Регенеруйте: pvecm updatecerts --force.
6. Перезапустіть pveproxy і перевірте за допомогою curl -kI https://127.0.0.1:8006/.

Чеклист D: Якщо підозрюєте часткове оновлення

1. Перевірте: dpkg --audit.
2. Відновіть: dpkg --configure -a.
3. Виправте залежності: apt-get -f install.
4. Переустановлюйте лише за потреби (цільово, не навмання).
5. Перезапустіть сервіси і повторно перевірте логи.

Поширені питання

1) Чи мої ВМ впали, якщо pveproxy не працює?

Зазвичай ні. pveproxy — веб/API‑проксі. Робочі навантаження можуть продовжувати працювати. Перевірте за допомогою qm list і pct list,
а також зовнішнє здоров’я застосунків.

2) Чому заповнений диск зупиняє веб‑інтерфейс?

Сервіси мають записувати логи, PID‑файли, кеші й тимчасові файли. Коли / заповнений, старти можуть провалюватися в спосіб, що виглядає не пов’язаним.
Перевіряйте df -h і df -i на початку.

3) Чи можна просто змінити порт UI Proxmox з 8006?

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

4) Який зв’язок між pveproxy і pvedaemon?

pvedaemon надає API/бекенд‑функціональність; pveproxy виступає фронтом по HTTPS. Коли plane‑керування ламається через /etc/pve або проблеми з ідентичністю, обидва можуть падати або поводитись неправильно.

5) Коли слід регенерувати сертифікати?

Коли сертифікати відсутні, недійсні або не відповідають — і лише після того, як ви підтвердили, що резолюція імен та час коректні, а /etc/pve відповідає.
Використовуйте pvecm updatecerts --force.

6) Мій браузер каже, що сертифікат недійсний. Чи означає це, що pveproxy зламався?

Не обов’язково. pveproxy може працювати коректно, але показувати сертифікат, якому браузер не довіряє (за замовчуванням самопідписаний) або сертифікат з CN, що не відповідає імені, яке ви використовуєте.
Перевірте openssl x509 і підключіться через очікуваний FQDN.

7) У кластері, чи кворум впливає на pveproxy?

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

8) Що робити, якщо /etc/pve повільний або зависає?

Розглядайте це як первинний інцидент. Перевірте pve-cluster і стан corosync. Уникайте редагування конфігурації під завислим /etc/pve;
це може погіршити неконсистентність. Спочатку відновіть здоров’я файлового шару кластера.

9) Чи варто мені перезавантажувати вузол, щоб виправити pveproxy?

Перезавантаження — останній засіб, а не перша дія. Воно може зняти завислий процес, але також стирає леткі докази і не вирішує кореневі причини, як‑от заповнений диск, DNS, зламані пакети або синхронізація часу. Якщо перезавантажуєте — зафіксуйте логи спочатку.

10) pveproxy працює, але UI недоступний із моєї робочої станції. Що робити?

Підтвердьте локальне здоров’я за допомогою curl -kI https://127.0.0.1:8006/. Якщо локально працює, проблема на мережевому шляху: правила брандмауера, маршрутизація, VLAN, зовнішні реверс‑проксі або корпоративні пристрої безпечного перехоплення TLS.

Висновок: подальші кроки, що запобігають повторенню

Померлий pveproxy рідко означає «тільки pveproxy». Це ваш plane‑керування, що каже: щось базове зламалося — сховище, ідентичність, час,
файловий шар кластера або цілісність пакетів.

Подальші кроки, які реально окупаються:

• Додайте моніторинг для кореневого диска та inode з алертами до 90–95% використання, а не при 100%, коли сервіси вже впали.
• Стандартизовуйте зміни ідентичності вузлів: зміни hostname/DNS повинні мати контрольовану процедуру, а не бути «пізно ввечері швидкою правкою».
• Практикуйте порядок виправлень у вікні обслуговування: збирайте логи, перевіряйте /etc/pve, лише потім чіпайте сертифікати і перезапуски.
• Робіть оновлення нудними: уникайте часткових оновлень, тримайте стан пакетів чистим і не змішуйте репозиторії без плану.
• Документуйте будь‑яку поведінку з нестандартними портами/проксі, щоб наступний інцидент не починався з розшук усього навколо.

Коли pveproxy.service failed знову з’явиться — а воно з’явиться — виконуйте план швидкої діагностики, поважайте порядок залежностей і не стирайте докази «допоміжними» перезавантаженнями.