Консоль Proxmox не відкривається (SPICE/noVNC): де ламається і як виправити

Як фактично працює консоль Proxmox (і де вона ламається)

Proxmox надає два основні шляхи доступу до консолей ВМ:

• noVNC (в браузері): веб-інтерфейс відкриває сторінку, яка встановлює WebSocket назад до вузла і проксує VNC-потік ВМ.
• SPICE (клієнт або запуск з браузера): інтерфейс генерує файл .vv і одноразовий квиток; SPICE-клієнт підключається через проксі.

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

Ланцюг noVNC (спрощено, але достатньо точно для діагностики)

1. Ви завантажуєте веб-інтерфейс PVE (зазвичай https://NODE:8006).
2. Інтерфейс запитує API короткоживучий VNC-квиток для VMID/CTID.
3. Інтерфейс відкриває сторінку noVNC і пробує встановити WebSocket-з’єднання до вузла (зазвичай теж через порт 8006).
4. pveproxy приймає WebSocket, перевіряє квиток і пересилає дані до локальної VNC-точки, яку надає QEMU.
5. QEMU говорить VNC. noVNC відмалює пікселі. Ви вводите — події клавіш повертаються назад.

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

Ланцюг SPICE

1. Інтерфейс просить SPICE-проксі-квиток і генерує файл .vv.
2. Ваш SPICE-клієнт читає файл і підключається до проксі-ендпоінта (часто через pveproxy на 8006, іноді через виділений порт залежно від конфігурації).
3. Проксі пересилає до SPICE-сервера QEMU (налаштованого для конкретної ВМ).

SPICE зазвичай відмовляє тому, що клієнт не може дістатися до вузла (маршрутизація/NAT), проксі неправильно рекламувало адресу вузла, або клієнт не приймає сертифікат/TLS.

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

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

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

Це шлях «припини гортати й полагодь». Мета — визначити, яке посилання ланцюга зламалося, за п’ять хвилин.

Спочатку: визначте, чи це браузер/інтерфейс, проксі вузла чи бекенд ВМ

1. Спробуйте безпосередньо за адресою вузла (не через VIP, не через зворотний проксі). Якщо консоль працює напряму, але не через фронтенд — винен ваш проксі/WAF/заголовки/TLS.
2. Перевірте DevTools → Console/Network у браузері на помилки WebSocket. Якщо бачите WebSocket connection failed або 401/403 для websocket-ендпоінта — це аутентифікація/квитки/проксі.
3. Перегляньте логи pveproxy і pvedaemon. Якщо там видно помилки квитків — виправляйте синхронізацію часу або проблеми з realm-аутентифікацією. Якщо логів немає — трафік не доходить (фаєрвол/проксі/маршрутизація).

По-друге: перевірте здоров’я вузла у питаннях консолей

1. Чи запущений pveproxy і слухає на 8006?
2. Чи узгоджений hostname/IP вузла з тим, що рекламує кластер? Невірна «рекламована адреса» ламатиме редиректи консолі дивними способами.
3. Чи синхронізовано час? Перевірка квитків чутлива до часу. Дрейф годин перетворює аутентифікацію на підкинуте монетою питання.

По-третє: перевірте бекенд консолі ВМ

1. Чи налаштовано ВМ для дисплея і чи він працює? (VNC або SPICE увімкнено, не відключено в конфі.)
2. Чи відповідає QEMU? Завислий QEMU може тримати ВМ «запущеною», але ніколи не приймати консоль.

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

Це реальні завдання, які можна виконати на вузлі Proxmox (або на адміністраторській робочій станції там, де зазначено). Кожне містить: команду, очікуваний адекватний вивід і наступні дії.

Завдання 1: Перевірте, що веб-проксі працює (шлюз консолі)

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:12:11 UTC; 2h 3min ago
   Main PID: 1322 (pveproxy)
      Tasks: 4 (limit: 38391)
     Memory: 62.4M
        CPU: 1min 12.204s

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

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

cr0x@server:~$ ss -ltnp | awk '$4 ~ /:8006$/ {print}'
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("pveproxy",pid=1322,fd=6))
LISTEN 0      4096            [::]:8006         [::]:*    users:(("pveproxy",pid=1322,fd=7))

Рішення: Якщо ніхто не слухає — консоль не працюватиме. Виправляйте pveproxy насамперед. Якщо слухає тільки на IPv6, а клієнти тільки IPv4 (або навпаки) — скоригуйте прив’язку або DNS.

Завдання 3: Перевірте очевидні помилки проксі в journal

cr0x@server:~$ journalctl -u pveproxy -S -2h --no-pager | tail -n 30
Dec 26 10:55:41 pve1 pveproxy[1322]: proxy detected vanished client connection
Dec 26 10:58:03 pve1 pveproxy[1322]: worker 1377 finished
Dec 26 11:12:09 pve1 pveproxy[1322]: starting 1 worker(s)

Рішення: «Vanished client connection» часто означає, що браузер/проксі/WAF закрив WebSocket. Якщо бачите помилки TLS handshake або проблеми з дозволами — це на боці вузла. Якщо журнал тихий під час кліку на Консоль — трафік імовірно не доходить (маршрутизація, фаєрвол, зворотний проксі).

Завдання 4: Слідкуйте за логом проксі при відтворенні проблеми

cr0x@server:~$ tail -f /var/log/pveproxy/access.log
10.10.20.55 - root@pam [26/Dec/2025:11:18:09 +0000] "GET /api2/json/nodes/pve1/qemu/101/vncproxy HTTP/1.1" 200 460
10.10.20.55 - root@pam [26/Dec/2025:11:18:09 +0000] "GET /api2/json/nodes/pve1/qemu/101/vncwebsocket?port=5901&vncticket=PVEVNC:... HTTP/1.1" 101 0

Рішення: 200 на vncproxy і потім 101 на vncwebsocket — це нормально: WebSocket успішно апгрейджено. Якщо бачите 401/403 — фокусуйтеся на аутентифікації/квитках/часі. Якщо websocket-запит взагалі не з’являється — перевіряйте заголовки браузера/проксі і підтримку WebSocket.

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

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-26 11:19:55 UTC
           Universal time: Fri 2025-12-26 11:19:55 UTC
                 RTC time: Fri 2025-12-26 11:19:55
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Рішення: Якщо System clock synchronized — no або NTP неактивний — виправте це. Квитки консолі короткоживучі; дрейф ламає їх так, що це виглядає як «випадкова нестабільність консолі».

Завдання 6: Перевірте адреси вузлів, які рекламуються в UI

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve1 (local)
         2          1 pve2

cr0x@server:~$ grep -R "^\s*address" /etc/pve/corosync.conf
        address: 10.10.20.11
        address: 10.10.20.12

Рішення: Якщо ці адреси недоступні з мережі вашого браузера (наприклад, вони на VLAN для зберігання або в приватній реплікаційній мережі), консолі будуть падати, коли UI спробує з’єднатися з «неправильним» інтерфейсом. Виправте стратегію адресації (маршрутизація або використання правильної IP для управління).

Завдання 7: Перевірте доступність порту 8006 з мережі клієнта

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

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

Завдання 8: Перевірте статус фаєрволу Proxmox і правила

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

cr0x@server:~$ iptables -S | head -n 25
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N PVEFW-FORWARD
-N PVEFW-INPUT
-A INPUT -j PVEFW-INPUT
-A FORWARD -j PVEFW-FORWARD

Рішення: Якщо фаєрвол ввімкнено — переконайтеся, що дозволили 8006/tcp з ваших адмінських мереж. Якщо ви маєте суворий локальний фаєрвол плюс upstream-фаєрвол, переконайтеся, що вони співпадають. «Оборона в глибину» чудова, поки обидва шари не сперечаються про те, хто дозволяє натиснути Консоль.

Завдання 9: Підтвердьте, що WebSocket-апгрейд працює на HTTP-шарі (на вузлі)

cr0x@server:~$ curl -k -I 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: 1783

Рішення: Якщо навіть це не працює локально — у вас зламаний проксі або TLS-стек. Виправте сервіси/серти на вузлі. Якщо локально працює, але зовні — це мережа або проксі перед вузлом.

Завдання 10: Відтворіть запит VNC-проксі через API (шлях аутентифікації і квитка)

cr0x@server:~$ pvesh create /nodes/pve1/qemu/101/vncproxy --websocket 1
port: 5901
ticket: PVEVNC:root@pam:6760E0C2::vO3o2oZ...
user: root@pam

Рішення: Якщо ця команда дає помилку (permission denied, блокування конфігурації кластера, таймаут) — проблема не в «браузері». Це API/аутентифікація/бекенд. Якщо повертає квиток і порт — серверну сторону можна згенерувати; ваша невдача, ймовірно, у транспорті WebSocket або політиці клієнта.

Завдання 11: Перевірте, що QEMU працює і не завис

cr0x@server:~$ qm status 101
status: running

cr0x@server:~$ ps -o pid,cmd -C kvm | head -n 3
  PID CMD
 2417 /usr/bin/kvm -id 101 -name vm101 -no-shutdown ...

Рішення: Якщо ВМ «запущена», але немає процесу QEMU (рідко, але буває розбіжність стану керування) — узгодьте через qm stop/qm start. Якщо QEMU є, але консоль все одно не працює — фокусуйтеся на проксі/квитках/фаєрволі.

Завдання 12: Перевірте конфігурацію дисплея ВМ (VNC/SPICE увімкнено?)

cr0x@server:~$ qm config 101 | egrep '^(vga|spice|serial|args)'
vga: std
serial0: socket

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

Завдання 13: Знайдіть помилки аутентифікації/квитків у логах демонів

cr0x@server:~$ journalctl -u pvedaemon -S -2h --no-pager | egrep -i "ticket|auth|permission|vnc|spice" | tail -n 20
Dec 26 11:18:09 pve1 pvedaemon[1203]: authentication successful: user root@pam
Dec 26 11:18:09 pve1 pvedaemon[1203]: VM 101: start vnc proxy

Рішення: Якщо бачите «authentication failed» або помилки квитків — перевірте синхронізацію часу і realm користувача, і переконайтеся, що браузер не кешує старі сесії між вузлами.

Завдання 14: Якщо ви використовуєте зворотний проксі, переконайтесь, що він дійсно проксує WebSocket

cr0x@server:~$ nginx -T 2>/dev/null | egrep -n "proxy_set_header (Upgrade|Connection)|proxy_http_version" | head -n 40
123:    proxy_http_version 1.1;
124:    proxy_set_header Upgrade $http_upgrade;
125:    proxy_set_header Connection "upgrade";

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

Завдання 15: Перевірте MTU/шлях, коли WebSocket підключається, але потім заморожується

cr0x@server:~$ ping -M do -s 1472 10.10.20.55 -c 3
PING 10.10.20.55 (10.10.20.55) 1472(1500) bytes of data.
1472 bytes from 10.10.20.55: icmp_seq=1 ttl=63 time=0.518 ms
1472 bytes from 10.10.20.55: icmp_seq=2 ttl=63 time=0.511 ms
1472 bytes from 10.10.20.55: icmp_seq=3 ttl=63 time=0.527 ms

Рішення: Якщо бачите «Frag needed» або втрати лише на великих пакетах — підозрійте невідповідність MTU (поширено при VLAN, тунелях або оверлейних мережах). WebSocket може «підключитись», а потім поводитися як привид під MTU-навантаженням. Виправте MTU; не заглушуйте проблему таймаутами.

Завдання 16: Перевірте DNS і відповідність імен в сертифікаті (особливо в кластерах)

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

cr0x@server:~$ openssl s_client -connect 127.0.0.1:8006 -servername pve1.example.internal 

cr0x@server:~$ openssl x509 -noout -subject -issuer -in /etc/pve/local/pve-ssl.pem
subject=CN = pve1.example.internal
issuer=CN = Proxmox VE

Рішення: Якщо UI доступний за ім’ям, що не відповідає CN/SAN сертифіката, браузери можуть блокувати або деградувати поведінку WebSocket залежно від політики й кліків користувача. Узгодьте URL доступу з іменами в сертифікаті або розгорніть правильні сертифікати по всьому кластеру.

Карта відмов: симптоми → місця зламу

Консоль — це інженерний механізм із багатьма частинами. Зіставте те, що ви бачите, з тим, де ланцюг міг обірватися:

Симптом: «Failed to connect to server (code: 1006)» або «WebSocket connection failed»

• Ймовірне місце зламу: WebSocket заблоковано або не апгрейджено.
• Дивіться: конфігурацію зворотного проксі, поведінку WAF, вкладку Network у DevTools, pveproxy/access.log (відсутність 101).
• Напрям виправлення: забезпечте заголовки Upgrade/Connection, HTTP/1.1 і довготривалі з’єднання. Якщо можливо — обійдіть зворотний проксі для шляхів консолі.

Симптом: вкладка консолі відривається, але залишається чорною/порожньою

• Ймовірне місце зламу: бекенд дисплея порожній (немає VGA) або дисплей QEMU неправильно сконфігурований; іноді під час passthrough GPU емульований VGA відсутній.
• Дивіться: qm config на vga/serial, гість може чекати інший первинний дисплей.
• Напрям виправлення: додайте серійну консоль, встановіть контрольний VGA-пристрій або переконайтеся, що гість виводить на правильну консоль.

Симптом: працює на одному вузлі, ламається на іншому

• Ймовірне місце зламу: фаєрвол на вузлі, невідповідність DNS/сертифікатів на вузлі або кластер рекламує інтерфейс, недоступний з адміністративної мережі.
• Дивіться: адреси corosync, маршрутизацію, стан pveproxy на проблемному вузлі.
• Напрям виправлення: стандартизувати мережу управління, уніфікувати сертифікати, не змішувати «IP зберігання» з «IP управління».

Симптом: SPICE завантажує .vv, але virt-viewer не підключається

• Ймовірне місце зламу: клієнт не може дістатися хоста/порту з .vv, або проблеми з TLS/довірою сертифіката, або неправильна рекламована адреса.
• Дивіться: вміст .vv (host, port), фаєрвол, NAT hairpin та адреси вузла.
• Напрям виправлення: переконайтеся, що .vv вказує на досяжну адресу; якщо за NAT — виправте маршрутизацію або використайте доступний VIP з коректним проксуванням.

Симптом: консоль працює, потім випадково обривається через хвилину чи дві

• Ймовірне місце зламу: таймаут бездіяльності на проксі/балансувальнику, або проблеми MTU/фрагментації на шляху, або агресивне обривання стану TCP у фаєрволі.
• Дивіться: таймаути проксі, налаштування conntrack фаєрволу, втрати пакетів, тести MTU.
• Напрям виправлення: збільшіть таймаути, дозволіть довгоживучі WebSocket-з’єднання, виправте MTU, припиніть робити «безпеку», яка вбиває сесії через 60 секунд.

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

1) Вічний індикатор завантаження в noVNC

Симптом: Вікно консолі відкривається, індикатор завантаження ніколи не зникає. Жодної очевидної помилки.

Причина: Зворотний проксі не підтримує або неправильно налаштований для апгрейду WebSocket на шляху до консолі.

Виправлення: Додайте заголовки апгрейду WebSocket і HTTP/1.1 у проксі або оминіть проксі для :8006. Перевірте наявність 101 у /var/log/pveproxy/access.log.

2) «401 Unauthorized» на vncwebsocket

Симптом: У DevTools браузера websocket-запит повертає 401/403.

Причина: Квиток недійсний/протермінований, часто через дрейф годин між вузлами, або sticky-сесії на балансувальнику працюють некоректно.

Виправлення: Налаштуйте NTP повсюди. Уникайте балансування UI PVE, якщо ви не розумієте афінність сесій і область дії квитків; краще використовувати VIP одного вузла зі сталістю бекенду.

3) Консоль працює лише в LAN

Симптом: На робочому місці працює; через VPN або з віддаленої мережі — ні.

Причина: Рекламовані адреси вузла на нерутованому інтерфейсі; або upstream-фаєрвол дозволяє 8006 лише з однієї підмережі.

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

4) SPICE завантажує .vv, але клієнт підключається до неправильної IP

Симптом: virt-viewer намагається підключитись до адреси VLAN зберігання, до якої ви не маєте доступу.

Причина: Хост вважає своїм «головним адресом» неправильний інтерфейс (поширено при multi-NIC і неакуратному DNS).

Виправлення: Виправте резолюцію імен вузла на management IP і уніфікуйте адресацію кластера. Не покладайтеся на «яку IP поверне DNS першою».

5) Консоль працювала, але зламалась після оновлення

Симптом: UI все ще завантажується; консоль тепер падає з TLS або помилками змішаного контенту.

Причина: Браузери посилили обробку TLS/WebSocket; ваш проксі або сертифікати і раніше були сумнівні, а оновлення прибрало останню толерантність.

Виправлення: Виправте сертифікати належним чином, узгодьте імена, припиніть подвійне термінування TLS без потреби і тестуйте консолі сучасними браузерами під час оновлень.

6) Порожня консоль на ВМ з passthrough GPU

Симптом: ВМ доступна по мережі, але консоль завжди чорна.

Причина: Вивід гостя йде на passthrough GPU; емульований VGA порожній.

Виправлення: Додайте серійну консоль для аварійного доступу і використовуйте її для діагностики завантаження. Не очікуйте, що VNC покаже вивід headless GPU.

7) Консолі падають лише в одному браузері

Симптом: Працює в Firefox, падає в Chrome (або навпаки).

Причина: Розширення/WAF, кешований HSTS/TLS, або суворіші правила щодо змішаного контенту.

Виправлення: Тестуйте в приватному режимі без розширень; порівняйте помилки в DevTools. Якщо браузер скаржиться на довіру сертифіката — виправте сертифікат; не привчайте персонал натискати «продовжити» на попередженнях.

Три корпоративні історії з польових умов

Міні-історія 1: Інцидент через невірне припущення

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

Під час рутинного технічного вікна один вузол перезавантажився і повернувся онлайн. UI виглядав здоровим. ВМ були запущені. Але консоль для будь-якої ВМ на тому вузлі не відкривалася з адміністративної мережі. Операційна команда припустила, що стек відображення ВМ зламався після перезавантаження і почала тикати налаштування QEMU. Вони були приблизно за 30 хвилин від того, щоб зробити гірше.

Справжня проблема була в припущенні, закладеному в мережевому плані: UI завжди буде спілкуватися з правильним інтерфейсом. Насправді hostname вузла резолвився в IP мережі зберігання, бо DNS «допомогли» оновити під час попереднього прибирання мережі. Proxmox рекламував цю адресу в UI для підключень консолі, тож браузери намагалися встановити WebSocket до недосяжної підмережі.

Виправлення було нудним: виправити DNS для імен вузлів на management IP і тримати мережу зберігання поза шляхом ідентичності управління. Консолі повернулися миттєво. Команда написала правило: «Якщо не доступно з адмінських мереж — воно не може бути ідентичністю вузла».

Міні-історія 2: Оптимізація, що дала зворотний ефект

Інша організація помістила Proxmox за корпоративним зворотним проксі. Мета була стандартизація безпеки: одна точка входу, одна політика TLS, одне місце для SSO. Команда проксі сильно заточила таймаути, щоб «захистити платформу» від довгих з’єднань. Вони також включили профіль WAF, що чудово фільтрував підозрілий трафік. Також він прекрасно блокував WebSocket.

UI завантажувався нормально. Це було достатньо, щоб визнати зміну успішною. Потім стався інцидент: оновлення гостя залишило ВМ непридатною для завантаження, і інженеру на чергуванні потрібен був доступ до консолі. Консоль крутила індикатор вічно. Інший інженер спробував SPICE. Та сама історія: завантаження файлу працювало, підключення — ні. Оптимізація проксі фактично забрала шлях аварійного доступу.

Дебаггінг був, як і годиться, політичним. Команда проксі казала, що Proxmox зламався. Команда віртуалізації казала, що проксі зламався. Обидві були наполовину праві: Proxmox потребує коректних апгрейдів WebSocket, а проксі був налаштований так, ніби все — статичні REST-запити.

Підсумок: обійти проксі для :8006 з адмінських мереж, зберегти SSO для UI там, де це має сенс, і явно дозволити Upgrade WebSocket та довгі таймаути для шляхів консолі. Усі вивчили ту саму науку різними словами: не все потрібно «оптимізовувати» в єдину форму.

Міні-історія 3: Сумна, але правильна практика, що врятувала ситуацію

Команда фінансових послуг мала строгий процес змін, який викликав у інженерів зітхання. У них був чек-лист перед оновленням: перевірити синхронізацію часу між вузлами, верифікувати сертифікати, відкрити консоль на кожному вузлі і запустити швидке сканування доступності з адмін-підмережі. Це було не гламурно. Це й не зламалося о 2 ранку.

Під час циклу оновлення Proxmox крок поновлення сертифіката провалився на одному вузлі через проблему з правами. UI все ще піднімався, що могло б приховати дефект. Але чек-лист включав «відкрити noVNC-консоль на тестовій ВМ на кожному вузлі», і консоль на тому вузлі відразу впала з TLS-помилкою.

Оскільки помилку виявили до продуктивного часу, команда встигла виправити її правильно: виправити права на файли сертифікатів і перезапустити pveproxy. Жоден аварійний доступ не було втрачено, і оновлення пройшло без драм.

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

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

Покроково: коли консоль зараз не відкривається

1. Обійдіть складність: підключіться безпосередньо до вузла на https://NODE:8006 (не через зворотний проксі, не через кластерний VIP) і протестуйте консоль.
2. Докази з браузера: відкрийте DevTools → Network, фільтр «websocket», відтворіть. Занотуйте статус-коди (101 vs 4xx/5xx) і помилки.
3. Докази з вузла: tail /var/log/pveproxy/access.log під час кліку Консоль. Шукайте vncproxy 200 і vncwebsocket 101.
4. Здоров’я сервісів: переконайтеся, що pveproxy працює і слухає на 8006.
5. Доступність: з вашої адміністраторської мережі перевірте TCP/8006 до вузла. Якщо не вдається підключитися — зупиніться і виправте мережу.
6. Квитки/аутентифікація: виконайте pvesh create ... vncproxy на вузлі, щоб підтвердити генерацію квитка.
7. Синхронізація часу: перевірте NTP і синхронізацію між вузлами. Виправте дрейф перш ніж гнатися за привидами.
8. Бекенд ВМ: перевірте qm config на налаштування дисплея/серіалу; підтвердьте наявність процесу QEMU.
9. Шар проксі (якщо є): перевірте заголовки апгрейду WebSocket і таймаути.
10. MTU/втрати пакетів: якщо підключається, але обривається — протестуйте MTU і перевірте conntrack/таймаути фаєрволу.

Покроково: жорсткі заходи, щоб це більше не повторювалося

1. Уніфікуйте адресацію управління: ім’я кожного вузла резолвиться в management IP, доступний з адмінських мереж. Без винятків «лише для зберігання».
2. Політика синхронізації часу: NTP обов’язковий на всіх вузлах; оповіщення при дрейфі. Квитки залежать від цього.
3. Гігієна сертифікатів: використовуйте коректні сертифікати з правильними іменами; безпечно оновлюйте; тестуйте після оновлення.
4. Правило для зворотного проксі: якщо ви мусите проксувати — явно підтримуйте WebSocket і довгі таймаути для шляхів консолі. Інакше — не проксуйте консолі.
5. Аварійний доступ: налаштуйте серійні консолі для критичних ВМ, особливо з passthrough GPU або headless конфігураціями.
6. Валідація оновлень: включіть тест відкриття консолі на кожному вузлі як частину контролю змін.

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

Цікаві факти та коротка історія (те, що варто знати)

• WebSocket стандартизували на початку 2010-х, і багато «корпоративної» HTTP-інфраструктури досі ставиться до них як до небажаного гостя.
• noVNC виник, бо «встановити клієнт» — неприйнятно в багатьох середовищах. Переміг браузер, а команди операцій отримали наслідки у вигляді проксі/заголовків.
• SPICE створювали не лише для пікселів: аудіо, буфер обміну, динамічні роздільності і кращий UX, ніж класичний VNC при енд-ту-енд використанні.
• Proxmox консолі використовують короткоживучі квитки з причин безпеки: зменшують область ураження в разі викрадених URL і обмежують повторне використання сесій.
• Дрейф годин ламає аутентифікацію несподіваними способами, особливо для систем, що видають токени з часовими обмеженнями. Квитки консолі — практичний приклад.
• Браузери поступово посилювали правила TLS і змішаного контенту. Старі налаштування сертифікатів працюють гірше з часом, особливо для WebSocket.
• Кластерні системи часто мають кілька мереж (управління, зберігання, реплікація). Змішування вибору адрес ідентичності між ними — класична причина «UI працює, а консоль — ні».
• VNC старий, але корисний. Його простота робить його простим для проксування; водночас вона ж робить його легким об’єктом неправильного захисту, якщо відкривати напряму.

Питання та відповіді

Чому UI Proxmox завантажується, але консоль падає?

Бо завантаження UI — це просто HTTPS на порт 8006. Консоль додає апгрейд WebSocket (noVNC) або окреме клієнтське підключення (SPICE) плюс короткоживучий квиток. Більше ланок — більше шляхів для відмови.

Який лог перевіряти найперше на вузлі?

/var/log/pveproxy/access.log. Він показує, чи надійшов websocket-запит і чи був апгрейдж (101). Це найшвидше джерело правди.

Що означає HTTP 101 у access.log?

Це означає, що апгрейд до WebSocket пройшов успішно. Якщо бачите vncwebsocket з 101, проксі і браузер погодили WebSocket. Якщо консоль все ще не працює — дивіться бекенд ВМ, MTU або рендеринг клієнта.

Чому зворотні проксі так часто ламають noVNC?

Тому що їх зазвичай налаштовують для коротких HTTP-запитів і вони можуть опускати заголовки апгрейду WebSocket, примусово використовувати HTTP/2, термінувати TLS так, що upstream плутається, або вбивати довгі з’єднання.

Чи можна «просто відкрити порт VNC» замість використання noVNC?

Можна, але зазвичай не слід. Це розширює поверхню атаки і ускладнює правила фаєрволу. Проксі-консоль Proxmox існує, щоб уникнути широкого відкриття VNC/SPICE-портів і прив’язувати доступ до автентифікованих квитків.

Чому це падає лише для деяких вузлів у кластері?

Невідповідна налаштування на вузлі: різні правила фаєрволу, різні сертифікати, різна резолюція DNS або вузол рекламує адресу, недоступну зі вашої адмінської мережі.

Як синхронізація часу пов’язана з консолями?

Квитки консолі мають часові рамки. Якщо час вузла достатньо неточний, квитки валідуються як прострочені або ще не дійсні. Результат — періодичні 401/403, що виглядають як нестабільність браузера.

Моя консоль підключається і потім обривається через ~60 секунд. Яка звична причина?

Таймаут бездіяльності проксі/балансувальника або налаштування стану в фаєрволі. Друга причина — невідповідність MTU, яка викликає дивні затримки під навантаженням. Виправте таймаути і MTU; не «вирішуйте» проблему постійними перепідключеннями.

SPICE не підключається, але noVNC працює. Чому?

Різні шляхи клієнта. SPICE використовує клієнтську програму і інший стек протоколу; він чутливіший до досяжності і довіри сертифікатів для ендпоінтів, вказаних у .vv. noVNC використовує те, що досяжне у браузера.

noVNC працює напряму до вузла, але падає через наш корпоративний URL. Що далі?

Переключайтеся з дебагу Proxmox на дебаг проксі. Забезпечте дозволи WebSocket, встановіть заголовки апгрейду, подовжте таймаути і перевірте, що правила WAF не блокують шляхи websocket.

Який найчистіший «break-glass» варіант для headless Linux ВМ?

Серійна консоль. Налаштуйте serial0: socket у ВМ, переконайтеся, що гість має серійний getty/кернел-консоль, і використовуйте серійну консоль Proxmox, коли VGA ненадійний.

Висновок: наступні кроки, які працюють

Коли консолі Proxmox не відкриваються, сприймайте це як ланцюг доступу/аутентифікації, а не як глюк UI. Ваш найшвидший сигнал — чи доходить vncwebsocket до pveproxy і чи апгрейджиться до 101. Далі — прямий триаж: доступність мережі, сумісний проксі для WebSocket, синхронізація часу для квитків і адекватна адресація вузлів.

Наступні кроки, що окупаються:

• Додайте «відкрити консоль на кожному вузлі» до ваших чек-листів при оновленнях і продовженні сертифікатів.
• Уніфікуйте DNS і інтерфейси управління вузлів, щоб консолі не перенаправлялися на недосяжні мережі.
• Прийміть зважене рішення щодо зворотних проксі: або налаштуйте їх коректно для WebSocket і таймаутів, або обходьте їх для доступу адміністраторів.
• Увімкніть серійні консолі на критичних ВМ, щоб вас не блокувало відсутністю VGA-виводу або його перенаправленням.

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