Choosing a VPN for Midjourney is not just about whether the website opens. Most daily activity takes place in Discord: the client maintains a gateway connection, sends interaction commands, receives task updates, and loads previews and original images from media nodes. Even when the Discord homepage opens, frequent long-connection rebuilds or missing proxy rules for image domains can leave commands waiting, delay results, or make thumbnails visible while original downloads fail.

To determine whether a route suits Midjourney, test “successful login,” “command response,” “image delivery,” and “persistent connection” separately. For route types, a stable IEPL route is often better for extended creative sessions; a reliable relay route balances cost and everyday use; a direct route depends more on the local carrier, international gateway, and time of day. The protocol name alone is not the answer. Split tunneling, DNS, and transport settings in the client also affect the result.

The takeaway: connection stability matters more than peak speed

For Midjourney, the priority should be connection continuity, packet-loss recovery, and a consistent exit region. Peak download speed comes last. A generation command uses little data, but it depends on a Discord session that stays online. During a brief route fluctuation, a speed test may still look excellent while the Discord gateway disconnects and rebuilds the session, delaying interaction updates.

Media delivery is a separate path. Preview images, enlarged images, and downloaded files may come from different media hosts. If the rules proxy only the main Discord site and omit media domains, text channels may work while the image area remains blank. When choosing a VPN or proxy service, confirm that the client can split traffic by domain or provide TUN mode for the relevant application traffic instead of relying only on a browser extension.

Brief conclusion: For extended Midjourney use, prioritize a stable IEPL route or a reliable relay route, and send the Discord gateway, interaction requests, and media domains through the same exit. For occasional use, a direct route can be tested, but homepage load speed alone is not enough to judge it.

Why the Discord connection is more demanding than a regular webpage

The gateway's persistent connection delivers events

After logging in, the Discord client connects to the gateway through a secure WebSocket connection. Channel messages, bot responses, and interaction updates are continuously delivered through it. When an ordinary webpage request fails, refreshing can retrieve the content again. A persistent connection must maintain session state and reconnect and recover after an interruption. Route instability, connection-tracking timeouts, or a sleeping proxy process can leave the client apparently open while event updates have actually stopped.

This is why “low latency” does not automatically mean “good for Discord.” A route may respond quickly to short requests, but if connection continuity is poor, messages can still arrive in frequent delayed batches. Conversely, a stable route with less impressive peak bandwidth may complete Midjourney's ongoing interactions more smoothly.

Interaction requests and media downloads are different traffic

When sending a command or clicking variation or upscale actions, the client creates interaction requests. Once generation is complete, images load from Discord content-delivery nodes. The two parts may match different domain rules. If the client proxies only the main domain, interactions may succeed while image requests continue over the local network. Media loading alone also does not prove that the gateway connection is stable.

The browser and desktop versions may use different network entry points. Browsers usually follow browser or system proxy settings, while desktop clients are affected by the operating system proxy, application behavior, and the way the client takes control of traffic. When the browser works but the desktop app does not, do not immediately change accounts. First confirm that the desktop application's connections are actually entering the proxy.

Keep the exit region consistent

Switching countries or regions repeatedly during a creative session can rebuild the Discord session and may trigger another login confirmation. A safer approach is to choose one sustainable exit and keep it unchanged until the current work is complete. The farthest exit is not necessarily the best. Consider the quality from the local network to the entry point, the transport path from entry to exit, and the connection from the exit to Discord infrastructure.

The key test is not “can it open?” but whether the same exit can carry login, persistent connection, interaction, and media delivery from start to finish. Only when all four are stable is a route suitable for a real Midjourney workflow.

Comparing route types: IEPL, relay, and direct

Route names describe the transport path and do not directly equal final quality. IEPL routes generally reduce uncertainty across the public international segment, making them suitable for persistent sessions and repeated image viewing. Relay routes connect to a nearby entry point before forwarding traffic to the target exit; their performance depends on entry quality and relay scheduling. Direct routes access overseas nodes from the local network with a simpler path, but are more exposed to changes in the local international gateway.

Route type Connection profile Suitable for What to watch
IEPL More controlled international path; persistent connections are usually more consistent Extended creative sessions, frequent interactions, repeated original-image viewing Entry quality and media-domain rules still need to be checked
Relay route Connects to a nearby entry point before forwarding traffic to an overseas exit Everyday use with a balance of stability and route choice Entry congestion or relay changes can affect persistent connections
Direct route Simple link structure; performance depends on the local international gateway Light use when the local network path is favorable Connection continuity may vary by time of day

Do not treat the “dedicated route” label as proof that testing is unnecessary. Even a suitable route type can fail because of wireless interference between the local network and entry point, incorrect client settings, or DNS that does not follow the proxy. Conversely, a quality direct route may work for short sessions when the local network is strong and the exit is reasonably close.

A practical method is to keep the client, exit, and test procedure fixed while changing only the route type. This reduces variables such as account state, browser cache, and device sleep. During testing, watch for Discord reconnect notices and check whether images load completely on the first attempt after generation, rather than recording download speed alone.

Protocol choice: the name is not the whole stability story

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC can all carry cross-border access traffic, but their transport methods, client support, and network behavior differ. Midjourney does not require a dedicated protocol. What matters is whether the protocol runs reliably on the current local network and whether the client correctly captures all relevant Discord requests.

Shadowsocks, VMess, Trojan, and VLESS

Shadowsocks is mature and widely supported by clients, making it suitable for standard proxying and domain-based split tunneling. VMess is common in proxy ecosystems and is typically combined with a transport-layer configuration. Trojan is based on TLS connections; its stability depends on the server, certificate configuration, and route quality. VLESS does not provide content encryption by itself and is commonly deployed with TLS or another secure transport layer, so it should not be judged separately from the full configuration.

These protocols often use TCP as the underlying transport, which is straightforward for Discord WebSocket connections. When packet loss is noticeable, TCP retransmits and reduces its sending pace. Messages and images may slow down, but the session does not necessarily stop immediately. If the server is congested or connections are frequently reset, changing the protocol name rarely solves the root problem; the entry point or route should still be changed.

Hysteria2 and TUIC

Hysteria2 and TUIC use QUIC and UDP transport. On networks with some packet loss or path variation, they may offer more flexible recovery. They can carry an application's TCP requests inside a proxy tunnel, but that does not turn Discord's WebSocket itself into UDP. The application-layer behavior is unchanged; only the underlying transport of the proxy tunnel differs.

Whether these protocols are suitable depends on UDP support on the current network. If a company network, public network, or router restricts UDP, the connection may fail to establish or may be less stable than a TCP-based option. In that case, keep a TCP transport node available as a fallback instead of repeatedly changing Discord settings.

Protocol group Main characteristics Meaning for Discord Common limitations
Shadowsocks Mature implementation with broad client support for split tunneling Suitable for standard persistent connections and media access Final performance depends mainly on the route and server load
VMess / Trojan / VLESS Can combine different security layers and transport methods Allows transport settings to be adapted to the network environment More configuration options mean incorrect combinations can prevent connection
Hysteria2 / TUIC QUIC and UDP based, with flexible recovery behavior May improve performance during fluctuations on compatible networks Affected by UDP availability and local network policies

Protocol conclusion: On a home network, start with a mature TCP-based configuration supported by the client. After confirming that the UDP path works, compare Hysteria2 or TUIC. Whatever the protocol, judge it by Discord connection continuity and complete image loading, not by its name.

Client split tunneling: include the gateway, interactions, and images

Subscription links usually contain node names, server addresses, ports, protocols, and authentication details. After importing one into a client, you still need to choose a proxy mode. Global mode is the easiest way to rule out missed proxy rules, but it sends other applications through the same exit. Rule mode is better for long-term use, provided all Discord- and Midjourney-related domains are matched. TUN mode takes over traffic at the system network layer and is useful when a desktop client does not fully follow the system proxy.

Protect subscription links like passwords. Authentication details in a link may allow others to use the associated service, so do not post them in public forums, screenshots, or visible areas of support tickets. When troubleshooting, provide a configuration summary with server addresses and authentication fields masked instead of sending the complete subscription.

Which requests should the rules cover?

At minimum, rules should cover the Discord main site, gateway, content delivery, and media hosts, as well as the Midjourney website itself. Domain structures may change, so prefer client-maintained rule sets and update subscriptions and rules regularly. Manual rules are useful for verification, but a temporary hostname should not be treated as a permanent list.

Rule outline:
Discord main site and gateway → specified proxy
Discord content delivery and media hosts → same proxy
Midjourney website and resource requests → same proxy
Local network and commonly used mainland services → direct
Unmatched traffic → choose according to actual needs

Using the same exit for gateway and media traffic reduces the difficulty of troubleshooting inconsistent session paths. If different rule groups automatically select different nodes, text events may enter from one region while image requests come from another. This configuration may not fail immediately, but it makes login state, cache hits, and connection stability harder to assess.

Traffic capture differs by platform

On Windows and macOS desktops, start by checking the system proxy and TUN mode. The Discord desktop app is built on Electron, but proxy inheritance is not identical across versions and system environments. When the system proxy works but the desktop app does not, TUN is often a useful troubleshooting method. After enabling TUN, also confirm local LAN requirements so that printers, storage devices, and other local addresses are not mistakenly sent through the proxy.

On iPhone and iPad, proxy clients usually capture traffic through the system VPN interface, with rules applied inside the client. Network changes, device sleep, or low-power policies may rebuild the tunnel. After returning to Discord, wait for the connection to recover before sending a command. Android client implementations vary more widely. Confirm that Discord is not on a bypass list and check whether the system limits the proxy client while it runs in the background.

The browser version is useful for cross-checking. If the browser and desktop app behave differently on the same node, the application capture scope is usually different; it does not necessarily mean the route itself is unusable. Compare the paths through the system proxy, TUN, and browser proxy instead of repeatedly switching exit regions.

DNS leaks and “connected but images do not appear”

DNS determines which address a domain resolves to. If traffic uses a proxy while DNS queries still go through the local network, the result may not suit the current exit or some domains may fail to resolve. The more common problem is split-tunneling mismatch rather than a privacy warning: the client needs the domain before it can apply the right rule. If the system resolves it first, the rule may see only a destination address and lose the ability to match by domain.

The solution is to keep DNS behavior consistent with the proxy mode. In rule mode, use the client's supported remote resolution or encrypted DNS and confirm that DNS requests follow the expected path. In TUN mode, check whether DNS hijacking or virtual resolution is enabled. If the browser has its own secure DNS enabled, confirm that it does not bypass the client's rules.

Missing images can also result from media domains bypassing the proxy, failed responses in the cache, the desktop app not entering the proxy, or the server still processing the image. First open the image address in a browser on the same device. If the browser works but the client does not, focus on application capture. If neither works, check media rules, DNS, and the route. If ordinary websites also fail, address the local network or proxy connection first.

Repeatable testing: compare routes with one process

A proper test should not rely on a single speed-test screenshot. A more reliable method is to keep the device, client, DNS, and exit region fixed, then compare routes in similar network conditions. Testing should cover session establishment, interactions, image loading, and recovery. Record observable behavior rather than concluding that one route “feels faster.”

  1. Set a local baseline. Temporarily stop large-file syncing, system updates, and other high-traffic tasks. Confirm that the current Wi-Fi or wired network is not disconnecting frequently.
  2. Fix the client configuration. Use the same proxy mode and DNS settings, import the latest subscription, and prevent automatic node changes during testing.
  3. Check exit consistency. After connecting, use a network-check page to confirm that the exit has changed, then start Discord. Do not switch regions during the test.
  4. Observe the gateway connection. Open several existing channels, check that messages appear continuously, and watch for repeated connection-recovery notices.
  5. Run a complete interaction. Send a normal Midjourney command and observe whether waiting status, completion notices, variations, and upscale actions return in sequence.
  6. Check media delivery. Open both preview and original images, confirming that a visible thumbnail is not hiding a failed download link.
  7. Simulate recovery. Switch away from the app briefly or let the device sleep, then return to Discord and check whether the session and image requests recover.
  8. Change only the route. Keep all other settings unchanged while testing IEPL, relay, and direct routes in sequence. Record reconnects, waiting time, and media-loading behavior.
Observed behavior First suspicion Next step
Ordinary messages also arrive in delayed batches Unstable gateway connection Change the route entry point and check TUN and background restrictions
Commands respond but images remain blank Media domains bypassing the proxy or DNS mismatch Complete the rules and send media requests through the same exit
Browser works but desktop app is abnormal Desktop application is not entering the proxy Check the system proxy and use TUN for cross-validation
Waiting continues after changing networks Tunnel or session has not recovered Reconnect the proxy and restart Discord
All clients fail at the same time Local network, route, or service status Check public status first, then test another entry point

The right order for diagnosing common failures

Discord shows online, but commands keep waiting

First send and receive ordinary messages in another channel. If ordinary messages work, check Midjourney service status and the current channel permissions. If ordinary messages are also delayed, inspect the gateway connection. Do not repeatedly submit the same command, as this can confuse task status. Close Discord, reconnect the proxy, and restart the client so that a new session is established from a fixed exit.

Preview images are visible, but originals will not open

This usually means that basic messages and some media requests succeeded, but the host serving the original image did not match the same rule or the cache retained an earlier failed response. Copy the image link into a browser on the same device and confirm that the browser uses the same proxy. If the browser works, return to desktop traffic capture. If it also fails, check media domains and DNS.

The route change requires another login confirmation

Frequent cross-region exit changes alter the session environment. After logging in, keep one region fixed and do not let automatic selection jump between countries. Automatic testing can help with initial selection, but during creative work it is better to lock a verified node. If switching is necessary, save the current work and fully restart the Discord session.

Voice works, but text or images do not

Discord voice, gateway, and media traffic are not identical. One working feature does not prove that every rule is correct. Check the application's TCP and UDP capture, domain split tunneling, and DNS separately. With only a browser extension, desktop and voice traffic generally do not automatically enter the extension proxy. In that case, use a system-level client.

Final guidance: choose by usage intensity, not node labels

If Midjourney is a regular creative tool, prioritize an IEPL route or a relay route verified through the complete process, and keep the exit region fixed. In rule mode, cover the Discord gateway, interactions, and media requests together. If the desktop app does not follow the system proxy, use TUN. Start with a mature, easy-to-fallback protocol configuration, then compare Hysteria2 or TUIC after confirming that UDP is stable on the local network.

If you generate images only occasionally, a direct route is worth testing, but the standard remains the complete workflow rather than homepage load speed. Every route can be affected by the local network, entry point, and usage environment. Keep a verified backup node and a stable client configuration. When a problem appears, separate service status, gateway connectivity, media routing, and DNS before switching nodes without a clear plan.

Ultimately, Midjourney network selection is a link-matching problem: the entry point must suit the local network, the transport must maintain Discord's persistent connection, the exit must remain consistent, and the rules must cover image delivery. Once each part has been verified, the practical differences between IEPL, relay, and direct routes become clear.