主控台打不開：介面一切正常，為什麼偏偏這一項失敗

其他一切都正常。能登入，樹狀清單會載入，可以瀏覽儲存空間、啟動機器。接著開啟主控台，它卻停住不動，或是立刻失敗，或是只顯示一個連線錯誤，其他什麼都沒有。

這個模式本身就是線索。整個介面都壞掉時，是整體性的問題。只有主控台壞掉時，則是特定的問題，可能的原因也很少。

最多人踩到的那一個

主控台並不使用一般的請求。它會開啟一條長時間存在的連線，一開始是一般請求，接著要求升級成持續的雙向通道。

瀏覽器和伺服器之間的任何東西，都必須願意轉送這個升級請求。放在 Proxmox VE 前面的反向代理，會很樂意轉送每一個一般頁面和每一個 API 呼叫，所以介面看起來完美無缺，然後卻把主控台丟掉，因為從來沒有人告訴它要處理這種連線。

官方的範例設定把需要的東西寫得很清楚，值得把它當成檢查清單來讀，而不是當成直接貼上的範本：

升級請求必須轉送過去。代理必須轉送升級請求，而不是自己回應它。

緩衝必須關閉。會先收齊整個回應才往下送的代理，會把互動式串流永遠扣住，看起來就和停住完全一樣。

逾時必須夠長。代理的預設逾時以秒為單位，因為一般請求都很短。開著一小時不關的主控台不是一般請求；官方發布的範例正是基於這個原因，把每一項逾時都設為一小時。

只要在 Proxmox VE 前面放了任何東西，在查看其他地方之前，先檢查這三項。症狀不會透露是三項中的哪一項，三者造成的都是同樣的沉默。

憑證的問題

主控台的連線是另一條獨立的連線，所以會自己再面對一次憑證的問題。

如果伺服器使用自我簽署的憑證，而當初是略過瀏覽器警告才進入介面的，那次接受不一定會延續到主控台的連線。頁面能載入，主控台卻不行，而且第二次不會再出現警告，因為那不是頁面載入。

直接造訪該位址一次，正式接受憑證，通常就能解決。如果主機不只一個人存取，這也是替主機換上正式憑證的好理由。

只有容器出問題時

如果虛擬機器的主控台正常，容器的主控台卻不行，就不必再往代理和網路查了。容器不模擬硬體；它的主控台是另一種機制，有自己的設定，問題出在那一側。

反過來的情況也很有參考價值：如果文字主控台在某台虛擬機器上失敗、在另一台上正常，那根本不是連線問題，而是缺少序列埠，本單元的另一篇文章有說明。

開出來的檢視器和預期的不同時

資料中心有一項設定可以選擇預設的主控台檢視器，它有一個文件中有記載、值得了解的行為：如果所選的檢視器不適用於該客體，就會退回圖形主控台。

這是合理的設計，但也代表主控台默默開成和設定不同的類型時，並不是壞了。它只是用最安靜的方式表示，原本要求的那一種無法使用。

依序排查的簡短步驟

直接在主機本身、透過主機自己的位址、中間不經過任何東西開啟主控台試試。如果在那裡可以正常運作，問題就在路徑上，而不在 Proxmox VE，該查的就是上面那三項代理設定。

如果在那裡也失敗，檢查是每個客體都失敗，還是只有一個。每個都失敗，指向伺服器或瀏覽器。只有一個失敗，指向該客體的設定。

查看瀏覽器開發者工具的主控台裡有沒有連線錯誤。它通常會精確指出失敗原因，比用猜的還快。

Atlas 的做法

Atlas 提供的是 Proxmox VE 本身的主控台，所以在 Proxmox VE 中失敗的主控台，透過 Atlas 也會失敗。沒有另一條路可以試，如果宣稱有，只會多出第二個需要除錯的東西。

Atlas 真正改變的，是需要主控台的頻率。打不開的主控台，只有在它是完成工作的唯一途徑時才算緊急狀況。儲存空間、網路、更新、權限和備份都有各自的畫面，所以壞掉的主控台就變成可以在悠閒的下午慢慢修的事，而不是在處理急事時撞上的一堵牆。