我們在使用 SSH 時面臨一個挑戰。每個虛擬機器 (VM) 都有一個標準的網址，我們同時用於 HTTPS 和 SSH，例如 undefined-behavior.exe.xyz。就像您可以在網頁瀏覽器中輸入網域名稱（並由 TLS 和驗證機制處理）一樣，您也可以執行：
對於網頁來說，這是一個早已解決的問題。許多網站可以也確實擁有相同的 IP 位址。網頁瀏覽器會在 HTTP 請求中，將用於連線到伺服器的網域名稱作為 Host 標頭發送。exe.dev 的代理伺服器會根據這個標頭進行切換，並將請求發送到適當的虛擬機器。
另一方面，SSH 沒有類似 Host 標頭的機制。如果我們在虛擬機器之間重複使用 IPv4 位址，我們就無法將 SSH 連線導向到正確的虛擬機器。
我們採用了一個公用 IPv4 位址池，而不是為所有虛擬機器使用一個 IP 位址。每個虛擬機器都會被分配一個相對於其擁有者的唯一位址。
因此，您會發現 A 記錄被替換為：
相對於擁有者，這表示雖然 s003 所代表的 IP 被許多虛擬機器使用，但它僅被該使用者擁有的單一虛擬機器使用。
這就是我們路由 SSH 連線所需的所有額外資訊。當 SSH 連線時，它會出示一個公鑰，並透過一個特定的 IP 位址連入。公鑰告訴我們使用者是誰，而 {使用者, IP} 這個組合則唯一識別了他們正在連線的虛擬機器。圖示如下：
建立一個執行此操作的代理伺服器需要一些跨系統的溝通：當我們建立一個虛擬機器時，我們必須根據擁有它的使用者（或在不久的將來：團隊）仔細分配一個 IP。我們的 SSH 代理伺服器必須能夠確定請求進入的本地 IP，這在裸機上很容易，但在雲端環境中則較為困難，因為公用 IP 會被 NAT 到私有的 VPC 位址上。所有這些都需要客製化的管理軟體，因此我們不建議將其作為一般解決方案推薦給想要將 VM SSH 存取多路複用在一個 IP 上的使用者。但統一、可預測的網域名稱行為對我們來說很重要，因此我們花時間為 exe.dev 建構了這個解決方案。