通訊埠編號只是一個提示，並不是防火牆原則。「常用網路通訊埠清單」工具收錄了 40 個經常遇到的 TCP 與 UDP 服務註冊資料，讓你可以把一個編號對應到可能的已註冊服務，但它刻意不是一份允許清單：由 IANA 指派並不等於背書，已註冊的服務名稱並不能證明身分，而一份通訊埠清單也無法取代真實防火牆規則所需的業務、方向、端點、協定、驗證與最小權限等決策。把一份精心整理的通訊埠表當作允許清單，會跳過把網路意圖轉化為安全原則的工作；同一張能幫你讀懂封包擷取的表，並不會告訴你流向特定主機 5432 通訊埠的流量，到底是合法的 PostgreSQL，還是你從未打算對外開放的設定錯誤服務。這份清單是用來回答「這裡可能跑著什麼」和「這個編號通常代表什麼」這類問題的參考資料，而不是可以直接貼進防火牆的規則。
「常用網路通訊埠清單」實際上包含什麼
常用網路通訊埠清單顯示一份精心整理的 40 個常見網路通訊埠表格。每一列包含一個數值通訊埠、選定的 IANA 服務名稱、相關的傳輸層協定（在需要區分時標示 TCP、UDP 或兩者）、一段簡明的白話說明，以及篩選器所用的分類。通訊埠依數值大小排序，且在表內不會重複；列出的項目涵蓋熟悉的網頁、郵件、檔案傳輸、遠端存取、目錄服務、資料庫、訊息傳遞、列印、容器以及核心網路服務。
這個工具不會假裝自己重現了整份 IANA 註冊資料。號碼空間其實大得多：IANA 將其劃分為 0 到 1023 的系統通訊埠、1024 到 49151 的使用者通訊埠，以及 49152 到 65535 的動態或私有通訊埠，而註冊範圍與慣例遵循 RFC 6335。一份收錄 40 列的精選清單涵蓋了常見的系統與使用者通訊埠，但刻意排除動態範圍，因此不在表中的通訊埠仍可能是有效、已註冊、私有、暫時性或依慣例廣泛使用的。表中沒有列出，只代表該通訊埠落在精選範圍之外。
搜尋會以不分大小寫的方式比對通訊埠編號、服務名稱、說明與分類，因此查詢 443 會回傳 HTTPS，查詢 PostgreSQL 會回傳 5432，查詢 mail 則可能回傳 SMTP、POP3、IMAP、訊息提交（message submission）以及它們的 TLS 變體。複製動作只會匯出目前可見的列，匯出格式為以 Tab 分隔的文字，適合用於工單、runbook、筆記或學習教材。所有的查詢與複製結果都不會離開這個頁面。
為什麼通訊埠清單無法取代防火牆原則
簡短的答案是：不行。「常用網路通訊埠清單」不是防火牆允許清單，工具本身也標示了這一點：防火牆原則需要經過驗證的業務目的、方向、端點、協定、驗證、加密、所有權與最小權限。一份通訊埠清單無法提供上述任何一項，因為每一項都取決於你所保護的具體主機、部署方式、組織與威脅模型。以下三個結構性原因讓這種替換變得不安全。
第一，通訊埠編號不等於身分。IANA Service Name and Transport Protocol Port Number Registry——也就是本工具各列所對照查驗的註冊資料——明確警告，指派並不背書某個應用程式，也無法證明觀察到的流量是良性的。一台伺服器可能監聽一個不常見的通訊埠，多個已註冊名稱可能共用同一個編號，而使用某個已註冊編號的封包，可能屬於與表中名稱不同的另一支程式。要確認實際執行的是什麼，必須檢查處理程序、設定、監聽中的 socket，以及真實端點上的流量，這些工作沒有任何靜態清單能代勞。
第二，同一個編號依設定不同，可能承載加密或明文流量。工具顯示 HTTPS 走 TCP，但同一個通訊埠上的伺服器也可能提供 HTTP、自訂的 proxy 或非網頁服務。因此，開放 443 在原則上並不是「開放網頁」；它只是開放監聽中的處理程序所接受的一切。比較 HTTP 與 HTTPS、IMAP 與 IMAPS、LDAP 與 LDAPS 等明文與 TLS 變體對學習有幫助，但加密的決策屬於服務設定層級，而不是通訊埠層級。
第三，精選表格優先呈現常見的營運使用情境，而非鉅細靡遺的完整收錄。例如，DNS 同時列出 TCP 與 UDP，而 HTTPS 只標示 TCP。這樣的選擇讓表格保持易讀，但它並不是對每種現代協定、擴充、替代註冊、廠商慣例或部署方式的權威性聲明。從這些列所建出的允許清單會繼承這些遺漏，悄悄地把你也許本來打算納入的服務排除在外。
一份真正的防火牆允許清單必須涵蓋哪些內容
一份可用的允許清單，必須從一個通訊埠表無法回答的問題開始：這個流量為什麼會存在？整個決策鏈通常會先經過好幾道篩選，才輪到通訊埠編號出場。下表對照了精選清單所提供的內容，與一條真正規則所需具備的屬性。
| 通訊埠清單所提供的內容 | 允許清單實際需要的內容 |
|---|---|
| 數值通訊埠 | 經驗證的端點（特定 IP、主機或 CIDR） |
| 已註冊的 IANA 服務名稱 | 方向（入站、出站或兩者） |
| 常見的傳輸層協定 | 實際在線路上觀察到的協定 |
| 簡明的白話說明 | 所使用的驗證機制 |
| 供篩選用的分類 | 加密需求與版本 |
| — | 業務負責人、工單與書面記載的目的 |
| — | 最小權限範圍與審查週期 |
右欄的每一項都無法從左欄推斷出來。每條規則都應該明確綁定一個端點與一項目的，範圍縮到能滿足業務需求的最小來源與目的地位址集合，並依據底層服務變動的頻率，排定定期審查的時程。通訊埠清單只能提供協定欄的初步猜測，而這個猜測還必須對照實際的服務設定、主機上的監聽 socket，以及你在封包擷取中觀察到的封包來加以確認。
若想看到不含防火牆論述的 40 個通訊埠平面參考資料，請參考「List of Most Common Network Ports: TCP and UDP」指南。清單本身的資料來源相同；差別在於本文把焦點放在允許清單的決策，以及你在採取行動前必須遵守的界線。
在做決定之前，先用清單識別一個通訊埠
「常用網路通訊埠清單」最有用之處是在原則工作之前的上游環節，而不是作為原則的輸入。當你在日誌、封包擷取、變更請求、廠商文件或來自其他團隊的工單中遇到一個不熟悉的編號時，這個工具會把那個編號轉成可能的服務名稱、可能的協定，以及一個可用來分流的分類。接下來，真正的驗證工作才開始：確認主機上的監聽處理程序、讀取服務設定、檢查線路上的協定是否符合預期，然後才決定是否該以防火牆規則放行這個流量，方向為何，以及要通往哪個端點。
分類篩選器是個實用的分流輔助。這個工具提供篩選器，可隔離出熟悉的群組，例如網頁服務、郵件、資料庫、遠端存取、核心網路基礎建設，而不會更動背後的參考資料。例如，當你懷疑某台是資料庫伺服器時，套用資料庫篩選會從 40 列縮到寥寥數列，讓你判斷看到的編號到底是不是某個已註冊的資料庫通訊埠，或者其實是別的東西。分流並不等於原則：在資料庫分類中對到一筆，仍必須在撰寫任何規則之前，先驗證端點、方向與目的。
| 篩選器 | 用途 |
|---|---|
| TCP 或 UDP | 在需要時區分傳輸層（DNS over TCP 與 UDP、HTTPS over TCP） |
| 網頁 | 隔離 HTTP、HTTPS 及相關的網頁流量 |
| 郵件 | 彙整 SMTP、POP3、IMAP、message submission 以及它們的 TLS 變體 |
| 資料庫 | 檢視 PostgreSQL、MySQL 等服務的通訊埠 |
| 遠端存取 | 找出 SSH、RDP、Telnet 及其他 shell 服務 |
| 網路基礎建設 | 檢視 DNS、NTP、DHCP 與核心網路服務 |
如何在「常用網路通訊埠清單」中查詢通訊埠
- 在搜尋欄位中輸入通訊埠編號、服務名稱、產品字詞或說明。隨著你輸入，比對會橫跨通訊埠編號、IANA 服務名稱、說明與分類進行，表格也會立即在瀏覽器中更新。
- 在需要區分時，可選擇依傳輸層協定（TCP 或 UDP）縮窄可見的列，或套用分類篩選器，例如網頁、郵件、資料庫、遠端存取或網路基礎建設，以隔離某一群服務。背後的參考資料不會改變，只有可見的列會改變。
- 檢視符合條件的註冊提示，確認該編號是否對應到你預期的服務。查詢 443 會回傳 HTTPS；查詢 PostgreSQL 會回傳 5432；查詢 mail 會回傳 SMTP、POP3、IMAP、message submission 以及它們的 TLS 變體。
- 當你需要把資料帶到工單、runbook、學習筆記或設定審查時，可將目前可見的列以 Tab 分隔的文字格式複製。複製動作只會匯出篩選後可見的內容，因此若想取得較小的片段，請先縮窄篩選。
- 若需要完整的指派資料、替代註冊、別名、變更歷程，或 SCTP 與 DCCP 的項目，請改用連結到的 IANA 註冊資料，而不是依賴這份 40 列的精選表。精選清單適用於常見案例的快速查詢；對於需要完整或時效性證據的決策，註冊資料才是權威來源。
What the Curated List Deliberately Excludes
The product contract is explicit about its limits so that you do not accidentally treat the table as more than it is. Five properties matter for the firewall question.
- The table is curated, not exhaustive. It does not reproduce every IANA assignment or change, and the transport list favors common operational use over every registry row.
- The dynamic port range from 49152 through 65535 is not enumerated. Ephemeral, private, and convention-driven ports sit outside the curated set, so absence here is not evidence of anything.
- IANA registration does not mean safety. The registry warns that assignment does not endorse any application, and the tool does not label any port safe or recommend firewall access.
- The tool does not scan a host, detect listening services, or replace packet inspection and authenticated system inventory. Verification of what is actually running has to happen on the endpoint with platform-native tools.
- No query or copied result leaves the page; processing is local. That is a privacy property, not a security verdict on the traffic the numbers represent.
For a decision that requires exhaustive or time-sensitive evidence, cross-check the IANA Service Name and Transport Protocol Port Number Registry directly and rely on platform-native tools, service configuration, logs, and your own network policy for the actual allowlist verdict. The curated list speeds up the lookup phase of that workflow; the policy phase still belongs to you.
If you're weighing options, How to Generate a Linux Directory Tree From Path Lists covers this in detail.