You log into your VPS to check on a strategy and the bottom-right corner of MetaTrader is showing “No connection” in red. The charts are frozen at some point in the past. The EA has not placed a trade in six hours. The immediate conclusion — the one almost everyone reaches — is that the VPS is broken.
It usually is not. In the great majority of cases the machine is fine, the network is fine, and something more specific has gone wrong: an account that was disabled, a server address that changed, a terminal that got stuck in a bad reconnect state, or a Windows setting quietly interfering. Each has a different fix, and applying the wrong one wastes a session.
This post gives you the diagnostic order to work through, from cheapest test to most involved, plus the permanent changes that stop the common causes from recurring.
First: Confirm What “No Connection” Actually Means
MetaTrader’s status indicator reports on one specific thing — the terminal’s link to your broker’s trade server. It does not report on your VPS’s general internet connectivity, and it does not report on your RDP session. Those are three separate paths and conflating them is the root of most misdiagnosis.
A useful mental model:
- Your PC → VPS is the RDP path. If this breaks, you cannot see the VPS at all, but the EA on it keeps trading.
- VPS → internet is the machine’s general connectivity.
- VPS → broker trade server is what the MetaTrader indicator measures.
The critical implication: if you can RDP into the VPS at all, path one is working. If a browser on the VPS loads a website, path two is working. So a red indicator with both of those working is a path-three problem — between MetaTrader and that specific broker server — and that narrows the search enormously.
📊 Key Stat: The single most common cause of a persistent “No connection” on an otherwise healthy trading VPS is not a network fault at all. It is an authentication failure — a changed investor or master password, an archived inactive account, or an expired demo — presenting itself as a connection problem because MetaTrader does not distinguish clearly between “cannot reach” and “was refused.”
The Diagnostic Order
Work through these in sequence. Each step is quick, and the order is deliberate — it eliminates whole categories before you start changing settings.
1. Check the Journal Tab, Not the Status Bar
The status bar says “No connection.” The Journal tab says why. Open Terminal (Ctrl+T) → Journal and read the last twenty lines.
What you are looking for:
- “Invalid account” or “Account disabled” — this is an account problem, not a network one. Stop here and contact your broker.
- “Authorization failed” — wrong password, or the password was changed elsewhere.
- “No connection to [server name]” repeating — genuine reachability problem, continue to step 2.
- “Connection lost” followed by successful reconnects — normal transient behaviour, not a fault.
This one step resolves a large fraction of cases in under a minute, and skipping it is why people spend an afternoon rebuilding a working VPS.
2. Test General Connectivity From the VPS
Open a browser on the VPS and load any website. If nothing loads, you have a machine-level networking problem and the broker is irrelevant. If sites load normally, the VPS’s internet is fine and the issue is specific to the broker path.
3. Test the Broker Server Directly
Get the actual hostname your terminal uses — it is shown in the login dialog and in the Journal — and ping it from a command prompt on the VPS. Our guide on extracting your broker’s MT4 server IP and DNS address walks through this.
Three outcomes:
- Replies normally — the server is reachable; the problem is inside MetaTrader or your account. Go to step 4.
- Does not resolve (DNS failure) — the address has changed or DNS on the machine is misconfigured.
- Resolves but times out — many brokers block ICMP by design, so this alone is not proof of a fault. Weigh it with the Journal output.
⚠️ Warning: A ping timeout is not evidence that your broker is down. A large number of trade servers drop ICMP deliberately while accepting trading connections normally on their actual port. Never rebuild a VPS on the strength of a failed ping alone — read the Journal first.
4. Re-select the Server in the Login Dialog
Brokers move, rename, split, and retire trade servers, particularly after platform migrations or when they add account types. Your terminal caches the old address and keeps trying it.
Go to File → Login to Trade Account, open the server dropdown, and check whether the server you are on still appears in the list. If the list looks different from what you remember, download a fresh installer from your broker’s client area — the broker-supplied build ships with a current server list, whereas a generic MetaQuotes download does not.
5. Rescan the Server List
In the login window, right-click the server field and choose to rescan or add a new broker server. This forces MetaTrader to re-resolve addresses instead of using its cached list. It fixes the “server exists but the terminal has a stale IP” case that step 4 alone does not.
6. Restart the Terminal, Then the Machine
Restart MetaTrader first — it clears a stuck reconnect state without disturbing anything else. Only if that fails, reboot the VPS.
Reboot last, not first. It is the step that destroys the evidence you would need for steps 1 through 5, and it fixes only a narrow class of problems.
The Causes Worth Understanding
Once you have found the immediate trigger, it is worth knowing why it happened, because most of these recur.
Broker-Side Server Changes
Brokers consolidate servers, rename them after rebrands, and migrate account groups between clusters. They usually email about it. That email usually arrives at an address you do not check, and the change lands while you are asleep. The terminal, still pointed at the retired address, sits in a reconnect loop indefinitely.
Account State Changes
Demo accounts expire, typically after 30 to 90 days of inactivity. Live accounts get archived after long dormancy, suspended pending re-verification, or restricted for compliance reasons. In each case the trade server refuses the login and MetaTrader presents it as a connection failure. The Journal will say so plainly.
Password Changes Made Elsewhere
Change your password in the broker’s web portal or in the mobile app, and every other terminal logged in with the old one starts failing. This catches traders running the same account on both a VPS and a laptop constantly.
Windows Firewall and Antivirus
A third-party antivirus or a firewall rule can block terminal64.exe outbound, usually after an antivirus update introduces a new heuristic. The symptom is a terminal that worked for months and then stopped without anything visibly changing. Our post on antivirus on a trading VPS covers which exclusions to set and why heavy consumer AV suites are a poor fit for a trading box.
Windows Update Restarts
An unattended restart takes the terminal down, and if auto-start is not configured, it never comes back. What you find later looks like a connection failure but is actually a platform that is not running. Control this with a proper Windows update schedule.
Genuine Network Events
They do happen — routing changes, upstream maintenance, a broker outage. These are typically short and resolve without intervention. The tell is that the Journal shows repeated reconnect attempts and then a successful reconnection, rather than a hard authorisation refusal.
Making It Not Happen Again
Diagnosis is reactive. These four changes are what actually reduce the frequency.
Configure auto-start properly. Terminal shortcuts in the Windows Startup folder, MetaTrader set to save the account password, and AutoTrading enabled by default. A machine that reboots at 4am should be trading again by 4:02 without you knowing it happened. For anything more robust than the Startup folder, our Task Scheduler restart guide covers watchdog-style setups that relaunch a terminal that has died rather than merely one that has not started.
Keep the VPS colocated with the broker. A short, stable path to the trade server experiences fewer transient drops than a long one crossing multiple networks. This is a reliability argument for colocation, separate from the usual execution-speed argument — see latency, jitter and packet loss.
Update the terminal from the broker, on your schedule. Running a build several versions behind eventually causes login failures when a broker requires a minimum build. Our guide to MT4/MT5 build updates on a VPS covers doing it at a weekend rather than mid-session.
Monitor, do not assume. Check the terminal is green at the same time each day. Many EAs and third-party utilities can send a Telegram or email alert on disconnection — for a strategy that matters, that alert is worth more than any amount of after-the-fact diagnosis.
💡 Tip: Keep a short text file on the VPS desktop with your exact server name, account number, broker support contact, and the date you last updated the terminal build. When something breaks at an awkward hour, having those four facts in front of you converts a thirty-minute hunt into a two-minute fix.
✅ Best Practice: After any disconnection that lasted more than a few minutes, check your open positions against the broker’s web portal rather than trusting the terminal alone. A terminal reconnecting after an outage occasionally shows a stale view until it finishes synchronising, and acting on a stale position list is a far more expensive mistake than the outage itself.
Summary
Red indicator does not mean broken VPS. Read the Journal first — it distinguishes an authentication refusal from a genuine reachability failure, and those have completely different fixes. Confirm general connectivity, test the broker host, re-select or rescan the server, restart the terminal, and only then reboot. Then close the loop with auto-start, a sensible update schedule, sane antivirus exclusions, and colocation that keeps the path short.
Frequently Asked Questions
Why does my MT4 say “No connection” when my VPS internet works fine?
Because they are different paths. The indicator reports only the terminal’s link to your broker’s trade server. Working internet on the VPS confirms general connectivity but says nothing about whether that specific trade server is reachable or whether your account was accepted.
Does a VPS disconnection close my open trades?
No. Positions and pending orders live on the broker’s server. A disconnected terminal cannot see or manage them, but stop losses and take profits set on the server continue to work normally.
My EA stopped trading but the terminal shows connected. What now?
That is a different problem — check that AutoTrading is enabled, that the chart shows the smiley face rather than the crossed-out icon, and that the EA has not hit an internal condition that stopped it. Our post on EAs that stop working on a VPS covers the usual causes.
How do I know if it is my broker or my VPS?
Read the Journal. An authorisation or account error is broker-side. Repeated “no connection to server” with working general internet on the VPS points to the broker path or a stale server address. Total loss of internet on the VPS is machine-side. Testing the same account from a second machine settles it definitively.
Should I reboot the VPS when MT4 disconnects?
Not first. Restart MetaTrader first — it clears stuck reconnect states and preserves the Journal evidence you need. Reboot only after the other steps fail.
Can antivirus software cause MetaTrader to disconnect?
Yes, and it is more common than people expect. An antivirus update can start blocking terminal64.exe outbound on a machine that worked for months. Add the terminal directory to your exclusions and prefer lightweight protection on a trading box.
Related Reading
- Navigating Technical Issues: Troubleshooting Your Forex VPS — the broader troubleshooting framework
- How to Extract the IP/DNS Address of Your Broker’s MT4 Server — needed for step 3
- Automating EA Restarts With Windows Task Scheduler — the permanent fix for restart-related outages
- Latency, Jitter and Packet Loss on a Forex VPS — why colocation reduces transient drops
- Antivirus on a Trading VPS — exclusions that prevent a whole class of false failures