選擇 Midjourney 加速器時，不能只看網頁能否開啟。Discord 桌面版或網頁版還要持續維持 WebSocket 長連線，傳送互動指令、接收任務狀態，並從圖片分發節點載入結果。一般網頁偶爾波動可能只需多等一會兒，但 Discord 長連線反覆中斷，會表現為指令停滯、按鈕點擊無回應、頻道內容延遲更新，甚至圖片一直停留在載入狀態。
因此，適合瀏覽國際網站的線路，不一定適合 Midjourney。真正需要確認的是連線穩定性、出口一致性、路由品質與用戶端接管範圍。以下先拆解完整通訊流程，再比較直連、中轉與 IEPL，最後提供可執行的協議選擇、分流與故障排查方法。
為什麼 Midjourney 能開啟，Discord 仍可能卡住
Midjourney 的 Discord 工作流程並不是一次普通的網頁請求。使用者在頻道中提交提示詞後，用戶端要將互動傳送給 Discord，持續接收頻道與任務狀態，再從相關網域與內容分發節點讀取圖片。任何一段未被正確代理，都可能讓流程停在中途。
最常見的誤判是「首頁能開，所以線路沒問題」。網頁首頁主要依賴短連線，請求失敗後瀏覽器通常會自動重試；WebSocket 則是一條持續存在的雙向連線。線路切換、出口位址變更、系統休眠、代理程序遭省電策略暫停，都會讓現有工作階段中斷。用戶端雖然可能嘗試重新連線，但重連期間送出的互動不一定能即時顯示結果。
另一類問題來自分流遺漏。瀏覽器可能已經走代理，但 Discord 桌面版仍依照系統預設路由連線；也可能主站網域已加入規則，圖片網域卻繼續直連。此時文字頻道看似正常，生成結果的縮圖卻無法開啟。反過來，若只代理圖片節點而 Gateway 未進入代理，頻道更新與按鈕互動仍會不穩定。
判斷線路是否適合 Midjourney，應完成一次連續流程：進入 Discord、提交互動、觀察任務狀態更新、開啟生成結果並下載圖片。只測試網站首頁，無法涵蓋長連線與 CDN 路徑。
挑選 Discord 線路要確認的四項指標
連線抖動比單次延遲更重要
延遲代表資料往返所需的時間，但單次顯示較低，不代表持續連線穩定。對 Discord 而言，更值得關注的是延遲是否頻繁波動、是否出現連續丟包，以及連線維持一段時間後是否重設。線路即使平均延遲不是最低，只要波動較小，互動體驗往往比「偶爾很快、偶爾斷線」的線路更可靠。
出口地區需要保持一致
登入期間不要頻繁在距離很遠的出口地區之間切換。出口變更會使原有 TCP、TLS 與 WebSocket 工作階段全部失效，Discord 用戶端必須重新建立連線。選擇與目前網路路由較為匹配、且能持續使用的出口，比在多個地區之間反覆追逐最低延遲更實際。
線路需要完整承載長連線
部分代理設定只涵蓋瀏覽器，或只代理規則清單中的常見網頁網域。請確認 Discord Gateway、登入介面、媒體資源及 Midjourney 相關請求都進入同一套可用路徑。使用規則模式時，也要留意網域變更與規則庫更新；規則不完整時，可暫時使用全域或 TUN 模式進行對照測試。
晚間壅塞與持續傳輸能力
生成圖片本身通常不是超大型檔案傳輸，但頻道更新、預覽載入與下載會持續使用線路。壅塞線路可能在短時間測速中表現正常，實際使用一段時間後卻出現排隊與重傳。測試時不要只重新整理一次頁面，應連續執行完整工作流程，並觀察同一出口在常用時段的表現。
- ✅ 連線 Discord 後可以持續更新頻道，狀態不會頻繁變成重新連線。
- ✅ 提交提示詞後，任務狀態與按鈕互動能持續更新。
- ✅ 預覽圖、放大結果與下載請求都能透過同一套分流規則。
- ✅ 固定使用出口時，延遲波動與丟包表現維持穩定。
- ❌ 只根據測速頁面的峰值頻寬判斷線路是否適合長連線。
- ❌ 每次卡頓就立刻切換到距離很遠的出口，導致工作階段反覆重建。
直連、中轉與 IEPL 專線有什麼差別
這裡的「直連」是指使用者網路直接連接境外代理入口；「中轉」是在中國大陸境內或鄰近地區增加入口節點，再由中轉鏈路送往境外出口；IEPL 通常指利用國際乙太網路專線承載其中一段跨境傳輸，再從境外閘道進入目標網路。三者描述的是傳輸路徑，不等同於具體加密協議。
| 線路類型 | 路徑特徵 | 對 Discord 的影響 | 適用情境 |
|---|---|---|---|
| 直連 | 本地網路直接連接境外入口，路徑受目前電信業者的國際路由影響較大 | 路由良好時結構簡單；壅塞或繞路時，WebSocket 更容易產生抖動 | 本地到目標地區的路由穩定，且希望減少中間環節 |
| 中轉 | 先連接較近的入口，再由服務端選擇後續鏈路與境外出口 | 可以避開部分不理想的直連路由，但體驗取決於入口與中轉段的品質 | 直連經常繞路，或不同電信業者之間的表現差異明顯 |
| IEPL | 跨境路徑中的一段由專線承載，境外出口後仍需存取公共網際網路 | 通常更重視路徑可控性與波動表現，但不能把「專線」直接理解為所有目標都不會壅塞 | 長時間使用 Discord，對持續連線穩定性的要求較高 |
IEPL 的價值主要在跨境區段，而不是讓整條請求路徑都脫離公共網際網路。資料抵達境外閘道後，仍要經過出口網路存取 Discord 與 CDN。因此，判斷 IEPL 是否合適，仍需實際檢查出口地區、境外互聯與用戶端規則。只看到線路名稱，不足以得出體驗結論。
中轉也不是層級越多越好。每增加一個轉發環節，就多一個可能壅塞或失效的位置。好的中轉會選擇更合適的入口與後續路由；不合理的中轉則可能增加延遲與故障範圍。測試時應固定協議、用戶端與出口，只替換線路類型，否則無法判斷改善究竟來自哪一項。
加速器協議怎麼選：Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC
協議會影響握手方式、傳輸承載、用戶端相容性與弱網路表現，但協議名稱本身不能取代線路品質。同一種協議套用在不同入口、路由與負載環境中，結果可能完全不同。選擇時應先確認用戶端支援，再根據目前網路是否限制 UDP、是否需要 TUN 接管，以及服務端提供的傳輸方式來判斷。
以 TCP 為基礎的常見選擇
Shadowsocks 結構相對直接，用戶端支援廣，適合需要簡單代理與規則分流的環境。VMess 與 VLESS 常由 Xray、sing-box 等核心支援，可搭配不同傳輸層；VLESS 本身不負責額外加密，通常需要與 TLS 等安全層正確組合。Trojan 的連線建立依賴 TLS 設定，適合用戶端與服務端都已正確提供憑證及傳輸參數的情境。
對 Discord 而言，使用 TCP 承載的方案通常具有較好的網路相容性。若所在網路對 UDP 不友善，先選擇穩定的 TCP 路徑更容易排除問題。不過，TCP 路徑一旦持續丟包，重傳與隊頭阻塞也會放大互動等待，因此仍要看實際線路，而不是只看協議標籤。
以 QUIC 與 UDP 為基礎的選擇
Hysteria2 與 TUIC 採用以 UDP 為基礎的 QUIC 設計，在部分高延遲、容易丟包的網路中，可以更靈活地處理並行串流與重傳。它們不保證在所有網路中更快：企業網路、公共 Wi-Fi 或部分路由環境可能限制 UDP，表現會變成連線失敗、握手緩慢或頻繁回退。
測試方法很直接：保持出口地區不變，分別使用可用的 TCP 與 UDP 方案執行相同的 Discord 工作流程。如果 UDP 協議頻繁中斷，而 TCP 能穩定維持頻道更新，就應優先考慮相容性；如果兩者都不穩定，則更可能是入口路由、出口壅塞、DNS 或分流問題。
不要同時更換協議、線路、出口與用戶端。一次只調整一個變數，並在相同網路環境下重新測試，否則即使短暫恢復，也無法定位真正原因。
用戶端匯入與分流規則如何設定
訂閱連結通常包含節點清單與連線參數，匯入用戶端後還需要選擇代理模式。匯入成功只代表用戶端讀取到設定，不代表 Discord 的所有請求都已進入代理。桌面版最容易出問題，因為瀏覽器、Discord 應用程式與系統 DNS 可能採用不同路徑。
- 匯入訂閱。在用戶端的訂閱管理中貼上服務提供的訂閱連結，更新後確認節點名稱與協議已正確解析。訂閱連結應視為存取憑證，不要發布到公開頁面或截圖中。
- 先進行全域對照。暫時使用全域或 TUN 模式測試 Discord 的完整流程。如果全域模式正常而規則模式異常，問題通常出在規則涵蓋範圍，而不是節點本身。
- 補齊網域規則。除了 Discord 主網域外，還要涵蓋登入、Gateway、附件與圖片分發相關網域，以及 Midjourney 網站和其實際呼叫的資源網域。網域可能調整，應以用戶端連線記錄與持續維護中的規則集為準。
- 統一 DNS 路徑。啟用用戶端提供的遠端解析、加密 DNS 或 TUN DNS 接管時，請確認網域解析結果與代理路徑一致，避免請求已經代理而 DNS 仍從本地網路送出。
- 固定出口重新測試。關閉自動切換，選擇一個出口完成登入、互動、載入與下載。確認穩定後，再決定是否恢復自動選擇。
Windows 與 macOS
Windows 用戶端常見系統代理與 TUN 兩種接管方式。系統代理主要影響遵循系統設定的應用程式，但部分桌面程式或背景連線可能不完全遵循；TUN 會在網路層接管更多流量，更適合判斷是否存在代理遺漏。macOS 也有系統代理與網路延伸模式，首次啟用網路延伸時需要在系統介面完成授權。如果瀏覽器正常而 Discord 應用程式異常，應優先以 TUN 或網路延伸模式進行對照。
Android 與 iOS
行動裝置用戶端一般透過系統 VPN 介面接管流量。Android 需留意省電策略是否暫停代理用戶端；系統回收背景程序後，Discord 的長連線也會一併中斷。iOS 切換網路、裝置休眠或低電量狀態也可能觸發重新連線。行動裝置排查時，應保持用戶端運作，並觀察狀態列中的連線標示是否持續存在。
DNS 洩漏與規則遺漏
DNS 洩漏是指網域查詢未依預期進入設定的解析路徑，仍由本地網路處理。這不一定會直接導致 Discord 斷線，但可能造成網域解析失敗、回傳不合適的節點，或讓分流規則無法依網域命中。可先在全域模式下使用本站的網路檢測核對出口與 DNS，再回到規則模式比較差異。
Discord 卡頓時的排查順序
排查應從最容易驗證的環節開始。不要看到圖片載入失敗就直接判定線路不可用，也不要因為網頁開啟正常就排除代理問題。以下順序可以逐步縮小範圍。
- ✅ 先確認代理用戶端仍處於連線狀態，訂閱沒有匯入錯誤或使用過期設定。
- ✅ 固定目前出口，重新連線後觀察 Discord 是否完成 Gateway 重連。
- ✅ 以瀏覽器版與桌面版進行對照，判斷是否只有桌面應用程式未被系統代理接管。
- ✅ 暫時切換至全域或 TUN 模式，檢查文字、互動與圖片是否同時恢復。
- ✅ 查看用戶端連線記錄，確認 Discord、附件 CDN 與 Midjourney 請求命中了代理規則。
- ✅ 對照 TCP 與 UDP 協議，判斷目前網路是否限制 QUIC 類傳輸。
- ❌ 在任務生成過程中連續切換節點，舊工作階段會被中斷，排查結果也會失去參考價值。
如果瀏覽器版正常、桌面版異常，優先檢查系統代理接管範圍與應用程式分流；如果文字正常但圖片異常，重點檢查 CDN 網域與 DNS；如果所有內容都會週期性停住，重點檢查 WebSocket 重連、線路抖動與系統省電；如果只有某個出口異常，則可能是該出口前往目標服務的境外路由問題。
自動選擇節點也可能造成干擾。部分用戶端會根據一次探測結果挑選最低延遲節點，但最低延遲不等於長連線最穩定。自動切換也可能在背景將工作階段移轉到另一個出口。用於 Discord 時，可以先關閉自動切換，在確認穩定的節點上完成一段連續操作，再決定是否啟用故障轉移。
完成排查後，保留一套已驗證的用戶端模式、協議與固定出口作為基準設定。日後遇到異常，先回到基準設定重新測試，可以更快區分本地設定變更與線路變更。
Midjourney 線路選擇結論
Midjourney 加速器的核心不是把某次測速做到最高，而是讓 Discord Gateway、互動介面與圖片分發請求穩定地沿著同一條可控路徑完成。選擇時依序檢視長連線抖動、出口一致性、路由類型與用戶端接管範圍，再根據目前網路對 TCP 或 UDP 的相容情況選擇協議。
直連適合本地國際路由本身穩定的環境；中轉可以改善部分繞路問題；IEPL 更著重跨境區段的路徑可控性，但仍需檢查境外出口與目標網路。用戶端方面，先用全域或 TUN 模式確認線路，再透過記錄補齊 Discord、Midjourney 與 CDN 的分流規則，同時讓 DNS 解析路徑與代理策略保持一致。