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

proxmox.lan {
 reverse_proxy 192.168.1.200:8006 {
   transport http {
     tls_insecure_skip_verify
   }
 }
}

Потрясающе! Всё сработало безукоризненно. Без участия пользователя Nginx_Proxy. Только настройка Caddy.

У меня тоже возникали проблемы с кластерами Proxmox на Caddy. Особенно это проявлялось при попытке подключиться к консолям через noVNC. Кажется, я исправил это, выбрав правильное правило балансировки нагрузки, чтобы клиент оставался на одном и том же бэкенд-сервере. Вот моя рабочая конфигурация из Caddyfile:

Code:  
proxmox.domain.com {  
   reverse_proxy * {  
       to server01:8006  
       to server02:8006  
       to server03:8006  

       lb_policy ip_hash     # Делает бэкенд «липким» на основе IP клиента  
       lb_try_duration 1s  
       lb_try_interval 250ms  

       health_uri /          # Путь для проверки здоровья бэкендов  
       # health_port 80      # По умолчанию такой же, как порт бэкенда  
       health_interval 10s  
       health_timeout 2s  
       health_status 200  

       transport http {  
           tls_insecure_skip_verify  
       }  
   }  
}

Caddy 2.6.2 на Ubuntu 22.04 LTS. Proxmox GUI 7.2-11.

Это действительно открывает возможность атаки "человек посередине", так как сервер Caddy примет любой сертификат от бэкенд-серверов, но если предположить, что Caddy и Proxmox находятся в одной локальной сети или даже на одной машине, риск, на мой взгляд, минимален. Если хотите избежать использования этой опции, нужно заставить Caddy доверять сертификату, который предоставляет Proxmox — либо добавив корневой сертификат PVE в доверенное хранилище корневых сертификатов сервера Caddy, либо прописав это в конфиге примерно так (взято с примера eivamu):

Код:  
proxmox.domain.com {  
   reverse_proxy * {  
       to server01:8006  
       to server02:8006  
       to server03:8006  

       lb_policy ip_hash      # Делает бэкенд "липким" на основе IP клиента  
       lb_try_duration 1s  
       lb_try_interval 250ms  

       health_uri /           # Путь для проверки здоровья бэкенда  
       # health_port 80      # По умолчанию такой же, как порт бэкенда  
       health_interval 10s  
       health_timeout 2s  
       health_status 200  

       transport http {  
           tls_trusted_ca_certs /etc/pve/pve-root-ca.pem  # Путь к корневому сертификату PVE  
       }  
   }  
}

Или можно сделать так, чтобы PVE использовал сертификат, подписанный публично доверенным УЦ, через опции ACME challenge, доступные в Node -> System -> Certificates.

Health_uri, будучи просто /, исключает ли это хосты, находящиеся на обслуживании, или, возможно, те, что не входят в кластер? Я ищу эндпоинты /live и /ready в API, но ничего подобного не нахожу... ссылка: https://testfully.io/blog/api-health-check-monitoring/#api-health-check-endpoint-types