節點、協定、分流是什麼意思？新手名詞一次搞懂

節點、協定、分流是什麼意思，是第一次匯入訂閱時最常見的疑問。它們並不是同一層概念：訂閱負責提供設定，節點代表可選擇的連線入口，線路描述資料實際經過的網路路徑，協定規定用戶端與伺服器如何通訊，分流規則則決定哪些要求走哪條路徑。拆開理解這幾個層次後，用戶端中的大多數選項就不再神秘。

新手常見的誤區，是把連線結果全部歸因於「節點好不好」。實際體驗還取決於本地網路、協定支援、入口位置、跨網路徑、出口位置、網域解析與目標網站。節點名稱看起來相同，也不代表底層路徑完全一致；協定名稱不同，也不必然代表速度有固定差異。

訂閱、節點與線路分別位於哪一層

訂閱連結不是線路本身

訂閱連結通常指向一份由伺服器產生的設定內容。用戶端存取這個網址後，讀取節點名稱、伺服器位址、連接埠、協定參數、驗證資訊、群組與規則等資料，再將它們顯示為可選擇的設定。不同用戶端支援的欄位不完全相同，因此同一份訂閱在不同軟體中可能呈現不同的群組或選項。

訂閱連結本身不會持續承載網頁流量。完成更新後，用戶端會依照匯入的設定連線至對應伺服器。也就是說，訂閱網址負責「取得設定」，節點位址負責「建立連線」。更新訂閱只是重新取得設定，不代表重新安裝用戶端，也不會自動修復所有網路問題。

由於訂閱網址可能包含用於識別設定的存取憑證，不應將完整連結貼到公開頁面、截圖或共用文件中。如果連結已公開，應從服務面板重新產生或更換訂閱，而不是只在本機刪除舊設定。刪除本機記錄無法讓已洩露的網址失效。

節點是入口與出口設定的組合

用戶端中的「香港」「日本」或「美國」等節點名稱，通常用來表示出口地區，但名稱只是服務方提供的標籤。一個節點設定至少要告訴用戶端連線到哪裡、使用哪種協定，以及如何完成驗證。伺服器收到流量後，再透過自己的網路路徑存取目標網站，因此目標網站通常看到的是伺服器的出口位址。

節點不能簡單理解成一台固定機器。實際服務可能在入口、傳輸與出口之間進行調度，也可能將多個入口彙整至同一個出口。判斷節點用途時，應優先查看出口地區、線路類型、協定相容性與目前網路表現，而不是只看名稱中的修飾詞。

線路描述的是中間路徑

線路關注的是資料如何從使用者端抵達出口。直連、中轉與專線是常見描述，但它們不是協定名稱。協定決定通訊格式，線路決定網路路徑；兩者可以組合。相同協定可以運作於不同線路上，同一條線路也可以承載不同協定。

常見協定名稱該怎麼讀

協定是用戶端與伺服器都必須理解的通訊規則。用戶端不支援某個協定時，即使伺服器位址、驗證資訊與網路都正常，也無法建立連線。協定還可能與傳輸方式、TLS、安全參數或偽裝層組合，因此只看到協定主名稱，並不能還原完整設定。

Shadowsocks

Shadowsocks 是一種加密代理協定，設定通常包含伺服器位址、連接埠、密碼與加密方法。其結構相對直接，用戶端支援度廣。加密方法必須與伺服器一致；舊版用戶端若不支援訂閱所使用的方法，可能無法連線或匯入後無法使用。

Shadowsocks 解決的是用戶端與代理伺服器之間的資料傳輸及驗證問題。它不會自動提供複雜的分流功能，規則通常由用戶端另外實作。看到「Shadowsocks 節點」時，應分開判斷協定相容性與實際線路。

VMess 與 VLESS

VMess 常見於 V2Ray 生態系，包含身分驗證、時間校驗與多種傳輸組合。裝置時間明顯不準時，部分設定可能因校驗問題而連線失敗。VMess 可以搭配不同傳輸方式，因此節點即使都標示 VMess，具體網路特徵也可能不同。

VLESS 採用較輕量的驗證設計，本身不負責提供完整的資料加密能力，通常依賴 TLS 或其他安全傳輸層保護連線。設定中的伺服器名稱、憑證驗證、傳輸方式與路徑參數需要彼此匹配。關閉憑證驗證或許能避開某些錯誤，但會削弱對伺服器身分的驗證，不適合作為長期處理方式。

Trojan

Trojan 通常運作於 TLS 連線之上，設定重點包括服務位址、密碼、伺服器名稱與憑證驗證。它的連線外觀接近常見 TLS 流量，但這不代表任何 Trojan 設定都會自動獲得更好的速度或穩定性。憑證、網域與伺服器名稱不一致，是常見的連線失敗原因。

Hysteria2 與 TUIC

Hysteria2 和 TUIC 都常採用以 UDP 為基礎的 QUIC 傳輸思路，重視壅塞控制、多路複用以及波動網路下的傳輸表現。它們在部分高延遲或容易丟包的網路中可能有較好的體驗，但前提是目前網路允許穩定傳輸 UDP。某些公共網路、企業網路或路由設備會限制 UDP，此時可能出現握手失敗、連線間歇中斷或無法回退等情況。

這兩類協定的用戶端版本與參數相容性也很重要。協定名稱相同但實作版本差異較大時，仍可能無法互通。遇到問題應先更新訂閱與用戶端，再確認伺服器端要求，不要任意複製另一種協定的參數。

分流規則究竟決定什麼

分流規則是用戶端的路徑選擇系統。瀏覽器或應用程式發出要求後，用戶端會根據網域、目標位址、應用程式程序、網路類型或規則集合，判斷該要求要走代理、直連或拒絕。分流發生在裝置端，因此在同一個節點下，不同網站可以使用不同路徑。

規則模式

規則模式會逐條比對要求。常見策略是讓本地服務與區域網路資源直連，讓需要國際線路的網域透過代理，再對廣告、追蹤或異常位址執行拒絕策略。規則模式通常更適合日常使用，因為能減少不必要的繞路，也能避免本地網站因出口地區變更而觸發額外驗證。

規則不只會比對瀏覽器網址列中的文字。網頁還會要求圖片、指令碼、介面、影片與第三方登入網域。如果主站走代理，但相依介面被錯誤設定為直連，頁面可能開啟但功能不完整。排查這類問題時，需要注意相關網域，而不是只將主網域加入規則。

全域模式

全域模式通常表示大部分由用戶端接管的流量都會經過所選節點。它適合短時間確認「是否是規則遺漏」：如果規則模式無法開啟，而全域模式可以開啟，問題很可能出在規則比對或網域解析；如果兩種模式都失敗，則應繼續檢查節點、協定、系統代理與目標服務。

全域模式不等於裝置上的所有資料一定都會被接管。用戶端採用系統代理、虛擬網卡或應用程式內代理，會影響涵蓋範圍。有些應用程式不讀取系統代理，有些應用程式使用自己的網域解析或網路堆疊，因此仍可能繞過一般系統代理。

直連模式

直連模式會繞過代理路徑，常用於存取區域網路裝置、本地服務，或確認問題是否來自代理設定。如果直連與代理都失敗，應先檢查本地網路與目標網站；如果直連正常但代理失敗，再檢查節點與協定；如果代理正常但直連失敗，則可能是本地網路路徑或存取地區差異造成。

• ✅ 日常瀏覽優先使用規則模式，讓本地服務與國際線路各自採用合適路徑。
• ✅ 頁面部分資源載入失敗時，暫時切換至全域模式，用來判斷是否有規則遺漏。
• ✅ 存取路由器、儲存裝置或區域網路服務時，確認相關位址維持直連。
• ❌ 不要把長期使用全域模式當成修復規則的替代方案。
• ❌ 不要在不了解來源時匯入會覆蓋現有規則的設定檔。

直連、中轉與 IEPL 專線有什麼差別

這裡的「直連」指的是線路結構，不是用戶端中的直連模式。線路直連表示用戶端直接連線至目標地區的代理伺服器，中間不經過服務方安排的額外中轉入口。它的結構簡單，但跨電信商與跨地區的路徑通常更依賴公共網路的路由選擇，晚間壅塞或跨網繞路會更直接地反映在連線體驗上。

中轉線路會先連線至較近或較容易抵達的入口，再由入口轉送至目標出口。這樣可以分別最佳化使用者端到入口、入口到出口的路段。中轉有助於避開部分不理想的公共路由，但也增加了一個需要維護的環節。入口正常而出口異常，或入口到出口之間發生問題，都可能導致節點無法使用。

IEPL 是國際乙太網路專線的常見縮寫，原本用於描述電信商提供的點對點企業網路連線。在訂閱服務的語境中，「IEPL 專線」通常表示入口與出口之間使用專線或類似的受控承載路徑，但使用者端到入口這一段仍需經過本地接取網路。它不等於從使用者裝置到目標網站的整條路徑都脫離公共網路，也不代表任何時段都不會受到本地網路影響。

因此，線路標籤只能幫助理解架構，不能取代實際判斷。較穩妥的方法是選擇符合自身網路的入口，觀察持續連線、網頁首次開啟、影片緩衝與檔案傳輸是否穩定，再比較不同線路。一次短時間測試只能反映當下狀態，不適合推導長期結論。

DNS 洩漏與網域解析為什麼會影響結果

使用者輸入網域後，裝置需要先將網域解析成網路位址。這個過程由 DNS 完成。如果網頁流量經過代理，但網域查詢仍由本地網路的解析伺服器處理，就可能出現 DNS 洩漏：本地解析方仍能看到查詢過的網域，而且解析結果可能與代理出口地區不一致。

DNS 洩漏不一定表現為「完全無法開啟」。更常見的現象是解析至不合適的內容傳遞節點、網站地區判斷不一致、主頁面能開啟但介面失敗，或在規則模式下出現循環判斷。用戶端通常提供系統解析、代理解析、加密解析或虛擬映射等方案，不同方案對相容性與分流精準度有不同影響。

規則需要網域資訊時，解析順序尤其重要。如果應用程式先將網域解析成位址，而用戶端只收到目標位址，基於網域的規則可能無法命中。具備虛擬網卡模式的用戶端通常能更完整地接管流量與解析，但也更容易與安全軟體、企業網路政策或其他網路工具發生衝突。

檢查 DNS 問題時，不要只看出口位址。還應確認解析伺服器所在的地區、瀏覽器是否啟用獨立的加密解析、用戶端是否接管 DNS，以及規則中是否存在將解析要求錯誤設定為直連的項目。修改後應清除系統與瀏覽器的解析快取，再重新建立連線。

不同平台如何匯入訂閱與更新用戶端

訂閱匯入流程大致相同：從服務面板取得訂閱網址，在相容用戶端中新增遠端設定，等待用戶端擷取節點，接著選擇群組、節點與運作模式。真正容易出錯的地方不是「貼上」動作，而是用戶端是否支援訂閱格式、協定與完整參數。

桌面平台

Windows 與 Linux 用戶端通常能提供較完整的系統代理、虛擬網卡、路由規則與連線記錄。系統代理只會影響願意讀取代理設定的應用程式；虛擬網卡模式可以接管更廣泛的流量，但需要相應的系統權限。遇到某個應用程式不走代理時，應先確認目前的接管方式，而不是直接認定節點失效。

macOS 用戶端同樣可能提供系統代理與虛擬網卡模式。系統升級、安全政策與網路延伸功能權限會影響虛擬網卡是否能啟動。用戶端顯示「已連線」只代表本地服務已執行，不一定表示遠端節點握手成功，仍需查看連線記錄或實際存取結果。

行動平台

Android 用戶端通常透過系統提供的 VPN 介面接管裝置流量，並可依應用程式決定是否經過代理。應用程式分流與網域分流是兩個維度：前者決定哪個應用程式進入用戶端，後者決定進入後採用哪條路徑。兩者設定衝突時，可能出現瀏覽器正常而特定應用程式無法連線。

Apple 行動平台上的用戶端同樣依賴系統網路延伸功能。背景政策、低電量狀態與網路切換可能影響連線維持。無線網路切換至行動網路後，如果連線看似存在但要求停滯，可以先重新連線，再判斷是否需要更新訂閱。

1. 從服務面板複製適用於目前用戶端的訂閱網址，不要根據聊天記錄中的截圖手動輸入。
2. 在用戶端新增遠端設定，確認匯入結果中出現節點與策略群組。
3. 選擇與用戶端相容的節點，首次測試時保留預設協定參數。
4. 啟用規則模式，開啟一般網頁驗證基本連線，再測試特定應用程式。
5. 需要判斷規則問題時，短暫切換至全域模式進行對照，完成後恢復規則模式。
6. 伺服器端設定變更後執行訂閱更新；如果更新失敗，檢查訂閱網址是否完整，以及網路是否能存取設定伺服器。

連線失敗時如何分層排查

有效排查依賴對照，而不是連續更換所有選項。一次只改變一個變數，才能知道問題發生在哪一層。先確認本地網路，再確認訂閱與用戶端，接著檢查節點、協定、線路、分流與 DNS。若同時更換用戶端、節點與模式，即使恢復連線，也無法知道真正原因。

• ✅ 關閉代理後，確認本地網路能正常存取常用服務。
• ✅ 更新訂閱並檢查節點清單是否完整，留意用戶端顯示的匯入錯誤。
• ✅ 確認用戶端支援節點使用的協定、加密方法與傳輸參數。
• ✅ 在同一個用戶端中切換不同線路，區分單一節點問題與整體設定問題。
• ✅ 使用規則模式與全域模式進行對照，判斷是否存在規則遺漏。
• ✅ 檢查系統時間、憑證驗證、DNS 接管與虛擬網卡權限。
• ✅ 閱讀用戶端記錄中的解析、握手、逾時或憑證錯誤，再決定下一步。
• ❌ 不要為了消除錯誤訊息而長期關閉憑證驗證。
• ❌ 不要在不清楚用途時修改壅塞控制、傳輸路徑或底層路由參數。

記錄中的「解析失敗」通常指向 DNS 或網域設定；「連線逾時」可能與網路無法連通、連接埠受限或線路異常有關；「憑證錯誤」應檢查裝置時間、伺服器名稱與憑證鏈；「驗證失敗」則應檢查訂閱是否過期、設定是否完整，以及用戶端是否錯誤修改驗證欄位。

如果某個節點在一種網路可用、另一種網路不可用，應重點比較電信商路徑、UDP 支援與本地裝置設定。如果所有節點在同一個用戶端中失敗，而同一份訂閱在另一個相容用戶端中可用，則更可能是用戶端版本、權限或接管方式的問題。如果所有用戶端都無法更新訂閱，則應先確認訂閱網址與設定伺服器是否可達。