Midjourney 使用哪款 VPN，不能只看網頁能否開啟。大部分日常操作都在 Discord 中進行：用戶端必須維持閘道長連線、傳送互動指令、接收工作狀態，再從媒體節點載入預覽圖與原圖。即使線路能開啟 Discord 首頁，只要長連線頻繁重建、圖片網域未納入代理，實際體驗仍可能是指令持續等待、生成結果遲遲不出現，或縮圖能看但原圖下載失敗。
因此，判斷線路是否適合 Midjourney，應將「成功登入」「指令回應」「圖片回傳」「持續連線」分開測試。線路類型方面，穩定的 IEPL 專線通常更適合長時間創作；品質可靠的中轉線路適合兼顧成本與日常使用；直連線路則更依賴本地電信商、國際出口及使用時段。協定名稱本身不是結論，用戶端的分流、DNS 與傳輸設定同樣會改變結果。
選擇結論：長連線穩定性優先於峰值速度
對 Midjourney 而言，優先順序應是連線連續性、丟包恢復能力、出口地區一致性，最後才是單次下載的峰值速度。生成指令本身資料量不大，但依賴持續在線的 Discord 工作階段。線路短暫抖動時，網頁測速結果可能仍很漂亮，Discord 閘道卻可能中斷並重新建立工作階段，導致互動狀態延遲更新。
圖片回傳是另一條鏈路。預覽圖、放大圖與下載檔案可能由不同媒體主機提供。如果規則只代理 Discord 主站，卻漏掉媒體網域，就會出現文字頻道正常、圖片區域持續空白的情況。選擇 VPN 或代理服務時，需確認用戶端能依網域分流，或提供涵蓋相關應用程式流量的 TUN 模式，而不是只提供瀏覽器擴充功能。
簡要結論：長時間使用 Midjourney，優先選擇穩定的 IEPL 專線或品質可靠的中轉線路，並讓 Discord 閘道、互動請求與媒體網域使用同一出口。偶爾使用時可以先測試直連線路，但不應只憑首頁開啟速度判斷。
- ✅ 登入 Discord 後能持續保持在線，不會反覆顯示重新連線。
- ✅ 傳送繪圖指令後，等待狀態與生成結果能持續更新。
- ✅ 頻道內的預覽圖、放大圖及原圖下載都能正常載入。
- ✅ 切換頻道或暫時離開視窗後，返回時不會長時間補收訊息。
- ✅ DNS 查詢與實際連線採用一致的分流邏輯。
Discord 鏈路為什麼比一般網頁更挑線路
閘道長連線負責推送事件
Discord 用戶端登入後，會透過安全的 WebSocket 連線至閘道。頻道訊息、機器人回應及互動狀態等事件，都依靠這條連線持續推送。一般網頁請求失敗後，重新整理即可取得內容；長連線則需要維持工作階段狀態，中斷後還要重新連線並恢復。線路抖動、連線追蹤逾時或代理程序休眠，都可能讓用戶端表面上仍開啟，實際事件卻暫停更新。
這也是「延遲低」不等於「適合 Discord」的原因。某條線路在短請求中回應很快，但如果連線連續性不佳，使用者仍會頻繁看到訊息延遲後集中出現。相反地，峰值頻寬不突出的穩定線路，往往能更順暢地完成 Midjourney 的連續互動。
互動請求與媒體下載並非同一種流量
傳送指令、點選變化或放大操作時，用戶端會產生互動請求；生成完成後，圖片再從 Discord 的內容分發節點載入。兩部分可能對應不同的網域規則。如果用戶端只將主網域加入代理，互動可能成功，但圖片請求仍走本地網路。反過來，媒體能載入也不能證明閘道長連線穩定。
瀏覽器版與桌面版也可能採用不同的網路入口。瀏覽器通常遵循瀏覽器或系統代理，桌面用戶端則同時受作業系統代理、應用程式實作及用戶端接管方式影響。遇到「瀏覽器能用、桌面版不行」時，不應立刻更換帳號，而應先確認桌面應用程式的連線是否確實進入代理。
出口地區應保持一致
創作過程中頻繁切換國家或地區，會讓 Discord 工作階段不斷重建，也可能觸發新的登入確認。較穩妥的做法是選定一個可持續使用的出口，在完成當次工作前保持不變。出口地區並非距離越遠越好，應綜合考量本地至入口的品質、入口至出口的傳輸路徑，以及出口至 Discord 基礎設施的連線狀況。
測試重點不是「能不能開啟」，而是同一出口能否完整承載登入、長連線、互動與媒體回傳。只有四個環節都穩定，才算適合 Midjourney 的實際工作流程。
線路類型比較：IEPL、中轉與直連
線路名稱描述的是傳輸路徑，不直接等同於最終品質。IEPL 專線通常能降低公網國際段的不確定性，適合持續在線及大量查看圖片；中轉線路先接入較近的入口，再由服務商轉送至目標出口，實際表現取決於入口品質與中轉調度；直連線路則由本地網路直接存取境外節點，路徑簡單，但較容易受到本地國際出口變化影響。
| 線路類型 | 連線特徵 | 適用情境 | 需要留意 |
|---|---|---|---|
| IEPL 專線 | 國際段路徑相對可控，長連線通常更連貫 | 持續創作、頻繁互動、連續查看原圖 | 仍需確認入口品質與媒體網域分流 |
| 中轉線路 | 先連接近端入口，再轉送至境外出口 | 日常使用，兼顧穩定性與線路選擇 | 入口壅塞或中轉切換會影響長連線 |
| 直連線路 | 鏈路結構直接，表現取決於本地國際出口 | 輕度使用、本地網路路徑良好時 | 不同時段的連線連續性可能有所變化 |
選擇時不要把「專線」標籤當成免測證明。即使線路類型合適，如果本地至入口受到無線網路干擾、用戶端設定錯誤或 DNS 沒有跟隨代理，Discord 仍可能異常。反過來，在本地網路條件良好、出口距離合理的情況下，優質直連也可能滿足短時間使用。
較實用的方式是固定用戶端、固定出口及固定測試流程，只替換線路類型。這樣可以減少帳號狀態、瀏覽器快取、裝置休眠等變數。測試期間也應觀察 Discord 是否出現重新連線提示，以及生成完成後圖片是否一次完整載入，而不是只記錄下載速度。
協定選擇：名稱不是穩定性的唯一答案
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 都可以承載跨境存取流量，但傳輸方式、用戶端支援及網路適應性各不相同。Midjourney 不要求特定專用協定；真正重要的是協定能否在目前的本地網路上穩定運作，以及用戶端能否正確接管 Discord 的所有相關請求。
Shadowsocks、VMess、Trojan 與 VLESS
Shadowsocks 實作較成熟，用戶端支援廣，適合一般代理與網域分流。VMess 常見於相關代理生態，通常會搭配傳輸層設定使用。Trojan 以 TLS 連線為基礎，能否穩定取決於伺服器、憑證設定及鏈路品質。VLESS 本身不負責內容加密，實際部署通常依賴 TLS 等安全傳輸層，因此不能脫離完整設定，只看協定名稱。
這些協定常以 TCP 作為底層承載，對 Discord 的 WebSocket 長連線而言通常較直觀。線路丟包明顯時，TCP 會重傳並降低傳送節奏，表現可能是訊息與圖片變慢，但工作階段未必立即中斷。若伺服器壅塞或連線頻繁遭重置，單純更換協定名稱通常無法解決根本問題，仍應更換入口或線路。
Hysteria2 與 TUIC
Hysteria2 和 TUIC 基於 QUIC 與 UDP 傳輸，在存在一定丟包或路徑波動的網路中，可能有更靈活的恢復表現。它們可以在代理通道內承載應用程式的 TCP 請求，但這不代表 Discord 的 WebSocket 本身變成 UDP。應用層語意沒有改變，改變的是代理通道的底層傳輸方式。
這類協定是否適合，取決於目前網路對 UDP 的支援。如果公司網路、公共網路或路由設備限制 UDP，連線可能無法建立，或穩定性反而不如基於 TCP 的方案。遇到這種情況，應保留一個 TCP 傳輸節點作為備援，而不是反覆修改 Discord 設定。
| 協定類別 | 主要特徵 | 對 Discord 的意義 | 常見限制 |
|---|---|---|---|
| Shadowsocks | 實作成熟，分流用戶端選擇較多 | 適合一般長連線與媒體存取 | 最終表現主要取決於線路與伺服器負載 |
| VMess / Trojan / VLESS | 可組合不同安全層與傳輸方式 | 方便依網路環境選擇傳輸設定 | 設定項目較多，錯誤組合會導致連線失敗 |
| Hysteria2 / TUIC | 基於 QUIC 與 UDP，恢復策略靈活 | 在適合的網路中可改善波動體驗 | 受 UDP 可用性與本地網路策略影響 |
協定結論：家庭網路可先使用用戶端支援成熟的 TCP 類設定；確認 UDP 路徑可用後，再比較 Hysteria2 或 TUIC。無論採用哪種協定，都應以 Discord 長連線與圖片完整載入作為判斷標準，而不是依協定名稱排序。
用戶端分流：將閘道、互動與圖片一併納入
訂閱連結通常包含節點名稱、伺服器位址、連接埠、協定及驗證資訊。匯入用戶端後，仍需選擇代理模式。全域模式最容易排除漏代理問題，但也會讓其他應用程式經過同一出口；規則模式更適合長期使用，不過需確保 Discord 與 Midjourney 相關網域完整匹配；TUN 模式則在系統網路層接管流量，更適合桌面用戶端未完全遵循系統代理的情況。
訂閱連結應像密碼一樣妥善保管。連結中的驗證資訊可能允許他人使用對應服務，不應貼到公開論壇、截圖或問題工單的可見區域。需要排查時，可以提供已遮蔽伺服器位址與驗證欄位的設定摘要，而不是傳送完整訂閱。
規則應涵蓋哪些請求
規則至少應涵蓋 Discord 主站、閘道、內容分發與媒體主機，以及 Midjourney 網站本身。網域結構可能調整，因此優先使用用戶端維護的規則集，並定期更新訂閱與規則。手動規則適合用於驗證，不宜將某個臨時主機名稱視為永久清單。
規則思路：
Discord 主站與閘道 → 指定代理
Discord 內容分發與媒體主機 → 同一代理
Midjourney 網站與資源請求 → 同一代理
本地網路與常用中國大陸服務 → 直連
未匹配流量 → 依實際需求選擇讓閘道與媒體流量使用同一出口，可以降低工作階段路徑不一致所造成的排查難度。如果不同規則群組自動選擇不同節點，文字事件可能從一個地區進入，圖片請求卻從另一個地區發出。這種設定雖不一定立即失敗，卻會讓登入狀態、快取命中及連線穩定性變得難以判斷。
各平台的接管方式不同
Windows 與 macOS 桌面版可優先檢查系統代理與 TUN 模式。Discord 桌面應用程式基於 Electron，但不同版本與系統環境對代理設定的繼承並不完全相同；系統代理可用而桌面版異常時，TUN 往往更適合作為排查手段。使用 TUN 後還要確認本地區域網路的存取需求，避免將印表機、儲存裝置等本地位址錯誤送入代理。
iPhone 與 iPad 上的代理用戶端通常透過系統 VPN 介面接管流量，規則由用戶端內部執行。切換網路、裝置休眠或低電量策略可能使通道重新建立，返回 Discord 後應等待連線恢復再傳送指令。Android 的用戶端實作差異較大，需要確認 Discord 未被加入繞過清單，同時檢查系統是否限制代理用戶端在背景執行。
瀏覽器版最適合進行交叉驗證。若瀏覽器版與桌面版在同一節點下表現不同，通常表示應用程式接管範圍不同，而不是線路本身完全不可用。此時應比較系統代理、TUN 及瀏覽器代理的路徑，而不是不斷切換出口地區。
DNS 洩漏與「連線成功但圖片不顯示」
DNS 會決定網域解析至哪個位址。如果連線透過代理，而 DNS 查詢仍由本地網路處理，就可能得到不適合目前出口的解析結果，或導致部分網域解析失敗。更常見的影響不是隱私提示，而是分流不匹配：用戶端必須先知道網域，才能將請求送入正確規則；解析過程若被系統提前處理，規則可能只能看到目標位址，無法依網域匹配。
解決方向是讓 DNS 與代理模式保持一致。規則模式應使用用戶端支援的遠端解析或加密 DNS，並確認解析請求本身遵循預期路徑；TUN 模式應檢查 DNS 劫持或虛擬解析功能是否啟用；若瀏覽器啟用了獨立的安全 DNS，也應確認它不會繞過用戶端規則。
圖片不顯示也可能是媒體網域漏代理、快取中的失敗回應、桌面版未進入代理，或伺服器仍在處理圖片。可以先在同一裝置的瀏覽器中開啟圖片位址：瀏覽器能開啟而用戶端不能，重點檢查應用程式接管；兩邊都不能開啟，重點檢查媒體規則、DNS 與線路；一般網站也異常，則先處理本地網路或代理連線。
可重現實測：依相同流程比較線路
所謂實測，不應只截取一次測速結果。更可靠的方法是固定裝置、用戶端、DNS 與出口地區，在相近的網路環境下依序比較線路。測試內容應涵蓋工作階段建立、互動、圖片載入及恢復能力，並記錄可觀察的現象，而不是憑「感覺較快」下結論。
- 確認本地基準。暫停大檔案同步、系統更新及其他高流量工作，確認目前 Wi-Fi 或有線網路本身沒有頻繁中斷。
- 固定用戶端設定。選擇同一種代理模式與 DNS 設定，匯入最新訂閱，避免測試過程中自動切換節點。
- 檢查出口一致性。連線後透過網路檢測頁確認出口已變更，再啟動 Discord，測試中途不要切換地區。
- 觀察閘道連線。開啟多個既有頻道，查看訊息是否連續出現，並留意用戶端是否反覆顯示連線恢復。
- 執行完整互動。傳送一般的 Midjourney 指令，觀察等待狀態、生成完成提示、變化與放大操作是否依序回傳。
- 檢查媒體回傳。分別開啟預覽圖與原圖，確認沒有只看得到縮圖、下載連結卻失敗的情況。
- 模擬恢復。短暫切換應用程式或讓裝置進入休眠，再返回 Discord，檢查工作階段與圖片請求能否恢復。
- 只替換線路。保持其他設定不變，依序測試 IEPL、中轉或直連，記錄重新連線、等待及媒體載入現象。
| 觀察現象 | 優先懷疑 | 下一步 |
|---|---|---|
| 一般訊息也延遲後集中出現 | 閘道長連線不穩定 | 更換線路入口，檢查 TUN 與背景限制 |
| 指令有回應但圖片空白 | 媒體網域漏代理或 DNS 不匹配 | 補齊規則，並讓媒體請求使用同一出口 |
| 瀏覽器正常，桌面版異常 | 桌面應用程式未進入代理 | 檢查系統代理，使用 TUN 交叉驗證 |
| 切換網路後持續等待 | 通道或工作階段尚未恢復 | 重新連線代理，再重新啟動 Discord |
| 所有用戶端同時異常 | 本地網路、線路或服務狀態 | 先查詢公開狀態，再更換入口測試 |
常見故障的判斷順序
Discord 顯示在線，但指令持續等待
先在其他頻道收發一般訊息。如果一般訊息正常，檢查 Midjourney 服務狀態與目前頻道權限；如果一般訊息也明顯延遲，則檢查閘道長連線。不要連續重複提交相同指令，以免混淆工作狀態。可以關閉 Discord、重新連線代理，再啟動用戶端，讓新工作階段從固定出口建立。
預覽圖可見，原圖無法開啟
這通常表示基本訊息與部分媒體請求已成功，但原圖位址對應的主機未套用相同規則，或快取保留了先前的失敗結果。將圖片連結複製到同一裝置的瀏覽器中測試，並確認瀏覽器也使用相同代理。若瀏覽器正常，應回頭檢查桌面版的接管方式；若瀏覽器也失敗，則檢查媒體網域與 DNS。
切換線路後要求重新確認登入
頻繁跨地區切換出口會改變工作階段環境。完成登入後應固定一個地區，不要讓用戶端的自動選擇策略在多個國家之間跳轉。自動測速可用於初步選擇，但創作期間更適合鎖定已驗證的節點。若必須切換，先儲存目前工作，再完整重新啟動 Discord 工作階段。
語音正常，文字或圖片異常
Discord 的語音、閘道與媒體流量並不完全相同。某項功能正常，不能證明所有規則都正確。應分別檢查應用程式的 TCP 與 UDP 接管、網域分流及 DNS。只使用瀏覽器擴充功能時，桌面用戶端與語音流量通常不會自動進入擴充功能代理，此時應改用系統層級用戶端。
最終建議：依使用強度選擇，不追逐節點標籤
如果 Midjourney 是持續使用的創作工具，應優先考慮 IEPL 專線或經完整流程驗證的中轉線路，並固定出口地區。用戶端採用規則模式時，要同時涵蓋 Discord 閘道、互動與媒體請求；桌面應用程式不遵循系統代理時，再使用 TUN。協定可先從支援成熟、方便回退的設定開始，根據本地網路是否穩定支援 UDP，再比較 Hysteria2 或 TUIC。
如果只是偶爾生成圖片，直連線路也可以測試，但判斷標準仍是完整工作流程，而不是首頁開啟速度。任何線路都可能受本地網路、入口及使用環境影響，因此應保留已驗證的備用節點，並儲存一套穩定的用戶端設定。遇到異常時，先區分服務狀態、閘道連線、媒體分流與 DNS，通常比毫無目的地反覆切換節點更有效。
歸根究柢，Midjourney 的網路選擇是一項鏈路匹配問題：入口要適合目前的本地網路，傳輸要能維持 Discord 長連線，出口要保持一致，規則還要涵蓋圖片回傳。分別驗證這些環節後，IEPL、中轉與直連的差異才具有實際意義。