8443
443 的非特權雙胞胎：一般使用者也綁得起來的 TLS 連接埠，也是 Tomcat 和多數設備管理主控台會伸手去拿的那個號碼。
照你的系統挑一行貼上去執行。它會直接印出占著這個連接埠的行程，以及它綁在哪個位址上——通常看到這兩件事答案就出來了。
sudo lsof -nP -iTCP:8443 -sTCP:LISTEN`-n` 和 `-P` 讓主機和連接埠維持數字，`-iTCP:8443` 選連接埠，`-sTCP:LISTEN` 選監聽狀態——這組搭配就是 lsof 手冊自己用的範例。PID 是第二欄，綁定位址是最後一欄，顯示成 `127.0.0.1:8443 (LISTEN)` 或 `*:8443 (LISTEN)`。綁在回送位址上，通常就是同事連不到你看得到的那個主控台的原因。如果 COMMAND 那欄寫的是 `java`，你看到的幾乎一定是 Tomcat 或另一台應用伺服器；能停服務就停服務，不要停行程。記得加 `sudo`，不然你只會看到自己帳號擁有的監聽者；連接埠空著的時候，lsof 不印任何東西並以 1 結束。
sudo ss -tlnp 'sport = :8443'照 ss(8) 手冊：`-t` 顯示 TCP socket，`-l` 只顯示監聽中的，`-n` 不解析服務名稱，`-p` 顯示所屬行程；`sport = :8443` 是它文件裡的連接埠過濾寫法。Local Address:Port 那一欄就是「為什麼其他人都連不到」的答案：`127.0.0.1:8443` 只有這台機器，`0.0.0.0:8443` 是每一個 IPv4 位址，`[::]:8443` 是 IPv6 萬用位址，通常連 IPv4 也一起收。行程顯示成 `users:(("java",pid=4310,fd=52))`。沒有 `ss` 的地方，`netstat -tlnp` 印出同樣的欄位，而兩者都要 root 才會點出不屬於你的行程。
openssl s_client -connect host.example.com:8443 -servername host.example.com這個探測回答的是另一個問題：不是誰占著連接埠，而是那裡到底是不是真的 TLS。`-connect host:port` 選目標，`-servername` 送出 SNI 擴充，虛擬主機的伺服器要先收到它才會拿出對的憑證。跑成功會印出憑證鏈、談成的協定和加密套件，然後停在那裡等輸入。交握立刻失敗，代表這個監聽者講的是別的東西——試試 `curl -v http://host.example.com:8443/`，看純 HTTP 會不會回應。需要完整憑證鏈來判斷少了哪一張中繼憑證時，加上 `-showcerts`。
netstat -ano | findstr :8443微軟的文件把 `-a` 寫成顯示所有作用中的連線和電腦正在監聽的連接埠，`-n` 是以數字表示位址和連接埠，`-o` 是為每條連線包含行程 ID。讀 Local Address 欄看綁定位址，讀 State 欄確認是 LISTENING，最後一欄是 PID；用 `tasklist /fi "PID eq 4310"` 去查它，這裡用的是文件裡的 `PID` 過濾條件和它的 `eq` 運算子。`findstr` 會比對整行任何位置的子字串，所以一條連到別台主機 8443 的已建立對外連線也會出現在同一份輸出裡——分辨兩者的是 State 那一欄。
Get-NetTCPConnection -LocalPort 8443 | Select-Object LocalAddress,LocalPort,State,OwningProcessPowerShell 的對應寫法，把連接埠當數字比對而不是文字，所以它不會撈到剛好出現在同一行別處的 `:8443`。對 `OwningProcess` 的值跑 `Get-Process -Id` 就能拿到執行檔。如果這個什麼都沒回，而你的伺服器還是綁不上去，那就是連接埠被保留而不是被占用——`netsh interface ipv4 show excludedportrange protocol=tcp` 會列出 Hyper-V、WSL2 和 Docker Desktop 開機時保留的範圍，落在裡面的東西綁定會失敗，而且找不到持有者。
`nmap -Pn -p 8443 app.example.com` 告訴你這個連接埠從主機外面看是什麼樣子，而那常常和在主機上看到的相反。`-Pn` 跳過主機探索、把目標當成上線的；`-p` 把掃描限制在這一個連接埠。`open` 代表交握完成，有東西在聽。`closed` 代表主機回了 reset，所以它碰得到但沒有人占著這個連接埠——那正是 TLS connector 從來沒被解除註解時你會看到的東西。`filtered` 代表探測封包消失、沒有任何回應，那是防火牆或安全群組把它丟了。`--reason` 顯示實際是三者中的哪一種：open 是 `syn-ack`，closed 是 `conn-refused`。`-sV` 會探測開著的連接埠以判定服務和版本資訊，而它是最快搞清楚 8443 上那個東西到底在講 TLS、還是只是把純 HTTP 擺在一個看起來很像的號碼上的方法。只掃你自己負責的主機。
| 你看到的訊息 | 代表什麼 |
|---|---|
curl: (35) LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version | curl 的結束碼 35 代表 TLS 交握失敗，而後面那串文字取決於 curl 是用哪個 TLS 函式庫建的——OpenSSL 版對同一件事會報另一行。原因幾乎一定是你要求 `https://`，而 8443 上的監聽者講的是純 HTTP。改抓 `http://host:8443/` 驗證一次；如果回得出頁面，連接埠是好的，錯的是 scheme。 |
The browser shows ERR_SSL_PROTOCOL_ERROR | Chromium 對網路錯誤 -107、也就是 `SSL_PROTOCOL_ERROR` 的稱呼，是上面那個故障的瀏覽器版本：有東西回應了，但回的不是瀏覽器完成得了的 TLS 交握。同一個網址改用 `http://` 試一次。如果純 HTTP 通，那這個服務就沒有在這個連接埠上設定 TLS，不管號碼看起來多像。 |
NET::ERR_CERT_AUTHORITY_INVALID | Chromium 的錯誤 -202，`CERT_AUTHORITY_INVALID`。對連接埠來說這是好消息：TLS 是通的，憑證也拿出來了，只是它沒有連到這台機器信任的根憑證——自簽憑證，或是一個從來沒被安裝過的私有 CA。網路沒有任何東西要改；把憑證解析出來，然後決定要不要信任它的簽發者。 |
Connection refused on 8443 while 8080 on the same host works | 經典的 Tomcat 樣貌。它內附的 `server.xml` 把 8443 的 TLS connector 註解掉，而還在運作的 8080 connector 依然宣告 `redirectPort="8443"`，所以任何被標記為需要安全通道的東西，都會把瀏覽器轉向一個沒有人在聽的連接埠。把 TLS connector 解除註解並設定好，或者改掉 `redirectPort`。 |
Error: listen EADDRINUSE: address already in use 0.0.0.0:8443 | 已經有另一個行程占著這個連接埠。因為 8443 很吸引管理介面，占著它的常常是某個被裝進來的東西，而不是你啟動的東西——設備的代理程式、同一台伺服器上一輪的執行，或是還在發布這個連接埠的容器。動手砍之前，先用你系統對應的探測指令找出持有者。 |
It works on the server itself but times out from anywhere else | 兩個可能，而探測指令一行就分得出來。要嘛監聽者綁到了 `127.0.0.1` 而不是一個路由得到的位址，那本機位址那一欄會直說；要嘛是防火牆把 SYN 丟掉了，那 nmap 會把這個連接埠報成 `filtered` 而不是 `closed`。逾時是被丟掉，被拒絕是瞬間的。 |
8443 是慣例，不是指派。IANA 登記表裡確實有這個號碼，但它對到的是 `pcsync-https`（PCsync HTTPS），跟全世界實際的用法毫無關係——所以照登記表自己的說法，把 8443 叫做「登記在案的 HTTPS 替代埠」是錯的。讓這個號碼黏住的，是讓 8080 黏住的同一套算式：在 Unix 系統上 1024 以下是特權連接埠，所以一台想要 TLS 又不想用 root 跑的伺服器，就拿 443 加上 8000。Apache Tomcat 是最清楚的例子。它內附的 `server.xml` 在監聽 8080 的明文 connector 上設了 `redirectPort="8443"`，同一份檔案裡也帶了一個給 8443 的 TLS connector——被註解掉，附一個範例 keystore。所以一台把你彈到 `https://host:8443/` 的 Tomcat，做的正是它預設設定寫的事，不管有沒有人把那個監聽者解除註解。號碼本身完全不代表有加密。瀏覽器是從 URL 的 scheme 決定要不要講 TLS，不是從連接埠，所以 `https://host:8443/` 只是一個送到不常見連接埠的普通 HTTPS 請求，而 `http://host:8443/` 就是一個普通的明文請求——這也是為什麼這個連接埠上最常見的故障，就是 scheme 和監聽者兩邊講的不是同一件事。
「8443 安不安全」背後其實藏了兩個各自獨立的問題。第一個是那裡到底有沒有 TLS。號碼什麼都沒承諾，一個在 8443 上回應明文 HTTP 的服務，在傳輸過程中和 8080 上的一樣看得懂，所以要查而不是假設：`openssl s_client -connect host:8443 -servername host` 要嘛完成交握並印出憑證鏈，要嘛立刻失敗、告訴你這個監聽者根本不講 TLS。第二個問題是它後面坐著什麼，而這就是這個連接埠名聲的由來。最後落腳在這個非特權 HTTPS 連接埠上的，管理介面的比例高得不成比例——應用伺服器主控台、設備的網頁 UI、建置伺服器、監控和 sidecar 端點——這些東西寫的時候都假設只有維運者找得到它們。掃描器掃 8443 和掃 443 一樣勤，所以一個不常見的號碼買不到任何隱蔽性。如果一個服務是給大眾用的，就在一台握有真憑證的代理上，於 443 終結 TLS 一次。如果它是管理介面，就不要從網際網路路由過去：綁在私有位址上，放到 VPN 或帶身分驗證的代理後面，並在防火牆上限制來源位址。自簽憑證在這裡很常見，因為這個連接埠實在太常是內部用的——請刻意決定你是要驗證那張憑證，還是要按掉警告，因為按掉警告的動作，和按掉一次中間人攻擊長得一模一樣。
這些全都在你的瀏覽器裡跑，不會上傳任何東西。
查 8443 的時候，通常也會順手看一下這幾個。
幾乎都是權限問題。lsof 和 ss 會列出 socket，但別人的行程它不會顯示所有者，所以由系統帳號、容器執行環境或 launchd 啟動的服務，在你補上 sudo 之前就只是一個沒有主人的監聽項。Windows 則是反過來：netstat 什麼都沒有，綁定卻還是失敗，那代表這個號碼落在 Hyper-V、WSL2 或 Docker Desktop 開機時預留的範圍裡。
先看清楚它是什麼。沒收乾淨的開發伺服器砍掉沒事；正在寫入的資料庫不行，其他東西依賴的系統服務也不行。如果持有者是容器，請停容器，不要砍主機看到的那個行程——砍了執行環境只會把它拉起來。遇到真的不能動的，把自己的服務換一個連接埠反而更快。
因為它綁在 127.0.0.1 而不是 0.0.0.0。每一頁的指令之所以會把綁定位址跟行程名一起印出來，就是為了這件事：綁在回送位址上的服務，不管防火牆怎麼設，都只有這台機器自己連得到。現在不少框架是刻意這樣預設的，所以通常是一個參數的問題，不是 bug。如果已經是 0.0.0.0 還是不通，下一個要懷疑的就是主機防火牆或雲端的安全群組。
幾乎沒有幫助。掃全網的機器持續在掃整段範圍，換號碼買到的是幾個小時，不是安全，代價卻是每個同事都得記住它。它確實能讓針對預設埠的無差別掃描少污染一點日誌，這算是實際但有限的好處。真正會改變結果的是認證、限制來源位址的防火牆，以及一開始就不要讓它對外。
連接埠 8443 還是卡住嗎？看完整的連接埠對照表，或是回到上面，從你實際看到的那行錯誤往回追。