The takeaway: stable persistent connections matter more than peak bandwidth
Choosing the best VPN for Midjourney takes more than checking a speed-test page or download rate. A complete Midjourney workflow through Discord includes the Discord gateway, prompt submission, status updates, image CDN delivery, and browser interactions. Even with high bandwidth, frequent connection resets, changing exit addresses, or incomplete routing can leave prompts stuck, freeze progress updates, show blank thumbnails, or make buttons unresponsive.
When comparing routes, first confirm that the Discord session stays connected. Then check whether image assets load completely, and only afterward compare full-size image opening and save speeds. For typical generations, stability is usually more important than burst throughput. Image delivery needs adequate bandwidth, but it is not a continuous large-file download; smooth operation depends on gateway messages and image assets following one predictable network path.
Which connections does the Discord workflow actually use?
After the Discord client starts, it performs DNS resolution and HTTPS requests before establishing a persistent gateway connection for event delivery. New channel messages, interaction states, and bot responses are updated through this session. Midjourney images are usually served from separate asset domains, so opening a channel and displaying an image are different tests.
After a prompt is submitted, the client sends the interaction request to Discord. Queue and generation status return through gateway events, while images load from a content delivery network. If routing rules proxy only the Discord site but omit the gateway or asset domains, the result can be a half-connected state: the text interface works, but progress does not update; or the task is complete while the image area remains a placeholder.
| Connection stage | Primary role | Symptoms | What to check |
|---|---|---|---|
| DNS resolution | Locate Discord and asset services | The page will not open, or asset domains fail to resolve | Check for conflicts between proxy DNS, system DNS, and the browser's secure DNS |
| HTTPS requests | Sign-in, channel loading, and interaction submission | The interface keeps loading, or prompts receive no response | Exit reachability, certificate time, and system proxy scope |
| Persistent gateway connection | Receive messages, queue status, and bot responses | The channel stops refreshing, then messages arrive all at once after recovery | Connection resets, network changes, and client sleep |
| Image asset delivery | Load thumbnails, full-size images, and generation results | Images are blank, loading stops, or full-size images open slowly | Check whether asset domains are routed correctly and whether packet loss is significant |
| Voice gateway | Carry Discord voice-call connections | Voice cuts out while text channels may continue working | UDP availability and client routing scope |
The voice gateway is part of the Discord ecosystem, but Midjourney image generation itself does not depend on voice calls. If the workflow only involves submitting prompts and viewing images, a route with strong voice performance should not automatically be considered better for generation. If Discord calls are also part of the workflow, verify the UDP path separately; a working text channel does not prove that voice traffic follows the same path.
How to choose between direct, relay, and IEPL routes
A direct route connects the local network straight to an overseas exit server, with a simple path and fewer forwarding steps. Its performance depends heavily on the local carrier network, the international path, and time-of-day changes. When the path is stable, direct routing is enough for Discord and Midjourney; when the international link fluctuates, gateway reconnects and incomplete image loads become more noticeable.
A relay route first connects to a nearby access node, then sends traffic through the relay network to the exit. Its value is not that it is inherently faster, but that it can avoid some unstable public-network paths and provide a consistent exit direction. Relay and exit nodes, along with the underlying network, all affect the result, so the label alone does not guarantee stability. Test the complete workflow.
IEPL typically organizes the access segment and international transport path more explicitly, with the goal of reducing uncertainty across the public international link. For workflows that keep a Discord gateway open for long periods, submit tasks continuously, and frequently load images, IEPL often fits a stability-first approach. Local access, node load, exit quality, and client settings still matter, so the route type cannot replace hands-on testing.
- ✅ Channel messages keep updating, and switching channels loads historical content promptly.
- ✅ After submitting a generation prompt, queue, progress, and completion states appear in order.
- ✅ Thumbnails, full-size images, variations, and upscales all open normally.
- ✅ After the computer sleeps or the network changes, Discord restores the session instead of remaining stuck on a connecting state.
- ❌ Checking only speed-test bandwidth without testing the persistent gateway and image assets.
- ❌ Frequently switching countries, nodes, or proxy modes during a single generation.
Different protocols do not directly indicate route quality
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC describe different proxy protocols or transport implementations, while IEPL, relay, and direct describe network paths. These are separate layers. The same protocol can run over routes of very different quality, and one underlying route may offer several protocol entry points. Protocol names alone cannot predict Midjourney's final performance.
Shadowsocks has a relatively straightforward setup and works well for common TCP and UDP proxy scenarios. VMess and VLESS are often combined with different transport methods, so results depend on the server, transport layer, and client implementation. Trojan is typically carried over TLS, but stability still depends on the underlying path. Hysteria2 and TUIC use QUIC and UDP, and may recover from congestion differently from TCP on networks with some packet loss; this assumes the local network and intermediate equipment do not restrict UDP.
Discord web requests and gateway connections can usually travel through a standard proxy, while voice features depend more heavily on UDP. For a Midjourney image workflow, focus on the gateway and CDN. If voice is also used, check whether the proxy client supports UDP forwarding and whether routing rules leave voice traffic on an unreachable local path.
| Protocol | Transport characteristics | What to check when using it with Discord |
|---|---|---|
| Shadowsocks | Lightweight proxy with broad client support | Confirm UDP support, DNS settings, and system proxy scope |
| VMess | Supports combining multiple transport methods | Do not judge by the protocol name alone; verify the actual transport configuration |
| VLESS | Flexible transport-layer configuration | Client compatibility and transport parameters must match |
| Trojan | Typically carried over TLS | Underlying route jitter can still affect persistent connections |
| Hysteria2 | Based on QUIC and UDP | Check whether the local network supports UDP |
| TUIC | QUIC-based proxy implementation | Pay attention to the client implementation, UDP path, and power use |
Exit consistency matters more than frequent route changes
Discord sessions, browser pages, and image assets should ideally use the same exit region. If browser traffic uses a proxy while the Discord desktop client stays on the local network, the two clients see different exit environments, making troubleshooting harder. If routing rules also send some CDN assets through another route, text may work while images fail.
When choosing a region, consider the path from the local network to the access node first, then the reachability from the exit to Discord services. A shorter distance does not guarantee a more stable path, and a longer distance does not necessarily make the service unusable. A more practical approach is to complete sign-in, channel loading, prompt submission, and image opening through one exit, then assess the entire path instead of switching repeatedly between regions.
Avoid switching nodes while a generation is in progress. The change interrupts the existing gateway connection, requiring the client to rebuild the session and retrieve state again. The task usually continues on the server, but the local interface may temporarily stop showing updates, making it look like generation failed. If changing routes is necessary, confirm the current task status first, then switch to a previously tested exit.
- Choose a region with a stable path to local access; do not prioritize the greatest geographic distance or the longest node list.
- Keep Discord on the same exit and confirm that channel lists, messages, and member status continue to refresh.
- Submit a prompt you normally use and check that interaction confirmation, queue status, and result delivery are complete.
- Open the full-size generated image, then run a common variation or upscale to confirm that all asset domains are routed correctly.
- If a problem occurs, record the failing stage and then try another route in the same region; do not change the protocol, region, DNS, and client at the same time.
How to check routing rules and DNS leaks
Global proxy mode is usually the easiest to verify because all Discord and image requests use the same exit, but it also sends local services that do not need a proxy through the detour. Rule-based routing is better for long-term use, but it must cover the Discord main domain, gateway connection, and related asset domains. Rules that are too narrow are a common cause of Midjourney half-connected states.
Here, a DNS leak mainly means that domain queries are not resolved through the proxy side as expected, separating the lookup path from the actual access path. It may not directly cause a connection failure, but it can return asset addresses that do not suit the current exit or expose the local resolution environment. If the client offers proxy DNS, remote resolution, or virtual DNS mode, enable it according to the software documentation and avoid letting the system, browser, and proxy use conflicting resolvers independently.
Troubleshoot routing from simple to complex. Temporarily use global proxy mode to verify the complete workflow. If global mode works but rule mode fails, the issue is usually rule coverage or DNS. Do not change routes first; review the target domains and matched policies in the connection log, then add rules for the Discord gateway and image assets. Return to rule mode and test again afterward.
Troubleshooting order
Verify the complete workflow with global proxy mode
→ Check whether the Discord gateway stays connected
→ Check whether image asset requests use the proxy
→ Verify the DNS query path
→ Restore rule mode and generate again- ✅ The Discord desktop client and browser use the same proxy scope.
- ✅ Gateway, main-site, and image-asset requests match the expected route.
- ✅ DNS queries are handled by one clearly defined configuration.
- ✅ Recheck the exit and routing status after switching local networks.
- ❌ Adding only the main-domain rule while ignoring dynamic assets and persistent connections.
- ❌ Assuming the route is faulty after global mode works without checking rule matches.
Windows, macOS, Android, and Linux differences
On Windows, system proxy and virtual network adapter modes are common ways to take control of traffic. System proxy mode mainly covers applications that follow system proxy settings, while virtual adapter mode can handle a broader range of traffic. If the Discord desktop client is not using the expected path, first confirm which mode is active and review the client connection log instead of repeatedly importing the subscription.
On macOS, network extensions or virtual network adapters usually require system authorization. Before authorization is complete, the proxy client may show as connected while some apps still use the original network. If Discord can sign in but stops refreshing after a system update, check the network extension status, DNS settings, and whether other network tools are taking control at the same time.
Android background restrictions can affect the proxy client and Discord's ability to keep running. If message updates pause after the screen turns off and appear all at once when the app is reopened, the cause may be background scheduling rather than the exit route. With per-app proxying, confirm that both Discord and the browser you use are included; proxying only one creates inconsistent exits.
System proxy support is not fully uniform across Linux desktop environments. A browser may follow desktop proxy settings while the Discord client may use a different path. When using a transparent proxy, virtual adapter, or explicit environment configuration, check that DNS and UDP are handled together. Command-line access to an asset does not prove that the desktop client uses the same route.
How to troubleshoot missing images and stalled queue updates
First identify which stage is failing. If Discord remains stuck on connecting, check gateway reachability, the system proxy, and network changes. If channel messages work but Midjourney status does not update, check whether interaction requests and bot messages are reaching the client correctly. If result text appears but images are blank, focus on CDN assets, DNS, and routing rules.
If restarting the client restores service briefly before updates stop again, the issue may be persistent-connection stability. Compare routes in the same region with different underlying transport, changing one variable at a time. If direct routing repeatedly reconnects while a relay stays stable, path organization may be the main difference. If every route behaves the same way, return to the client mode, system time, DNS, and local network environment.
Slow image loading does not necessarily mean generation is slow. Midjourney server queueing, generation, and image download are separate stages. If the interface shows the task as complete but the image opens slowly, the issue is more likely image delivery. If there is no status change for a long time, check gateway messages first. Separating the stages prevents adding bandwidth to solve a persistent-connection problem.
A repeatable method for choosing a Midjourney route
Keep the client and protocol fixed, and compare only route paths. Determine whether direct, relay, or IEPL routing can reliably complete channel refreshes, prompt submission, and image delivery. Then keep the best-performing route fixed and compare protocols for compatibility with the current network. This separates route differences from protocol differences and avoids conclusions based on one accidental reconnect.
After selecting a route, narrow from global mode to rule-based mode. Change one setting at a time and preserve the steps that reproduce the problem. If switching between desktop and mobile, verify each platform's proxy coverage separately; importing the same subscription does not guarantee identical behavior.
For long-term use, keep one tested backup route. Test the backup in advance for sign-in, message refreshes, and image delivery instead of choosing randomly from a list after a failure. A stable exit, clear routing, and repeatable troubleshooting matter more to the real Midjourney and Discord experience than a node name or one speed-test result.