An FTP client that connected fine on the previous host and now times out or hangs on SiteGround is rarely a credentials problem. SiteGround’s shared hosting enforces a specific set of connection rules that most other hosts either do not enforce at all or enforce more loosely, and an FTP client still using its old settings from the previous host will run straight into one of these limits without producing an error message that clearly explains why.
This distinction between “credentials wrong” and “connection rules mismatched” matters because the two problems look deceptively similar from the outside but call for completely different troubleshooting paths. A genuine credentials problem produces a clear authentication failure immediately, before the client ever attempts to list a directory or transfer a file, and the fix is simply re-entering the correct username and password. The connection rule mismatches this article focuses on instead, produce a connection that authenticates successfully, appearing to confirm the credentials are correct, and then fails or hangs at a later step entirely unrelated to the login itself. Recognizing which category a given failure falls into early saves considerable time that would otherwise be spent re-checking and re-entering credentials that were never actually the problem.
This article covers the specific things that change when switching to SiteGround: why passive mode is not optional here the way it might have been elsewhere, the 4-minute idle timeout that has no override option even on paid plans, the 8-connection-per-IP limit that produces the confusing 421 error, the DNS propagation trap that has a client silently connecting to the old host during a migration, and the exact FTP hostname and credential location in SiteGround’s Site Tools interface, which looks nothing like the cPanel layout most people are used to.
Passive mode is required, not optional, on SiteGround
FTP has two connection modes, active and passive, and the difference determines which side of the connection opens the data channel used for transferring file listings and file contents. In active mode, the server attempts to open a connection back to the client, which almost always fails against a modern home or office network sitting behind a router or firewall performing network address translation, since that router has no way to know an unsolicited incoming connection from the FTP server is expected and legitimate. In passive mode, the client opens both connections to the server instead, which works reliably through virtually any modern router or firewall without special configuration.
This distinction matters more today than it did when FTP was first designed, precisely because almost every network in active use now sits behind some form of NAT, whether that is a home router, an office firewall, or a mobile carrier’s own network address translation layer. Active mode was a reasonable default in an era when most machines had a direct, publicly routable IP address, but that networking model is now the exception rather than the rule, which is exactly why passive mode has become the practical default across the FTP ecosystem even though many clients still ship with active mode or automatic detection as their out-of-box setting rather than passive mode explicitly enabled.
Some budget or older hosting environments are lenient enough that an FTP client defaulting to active mode still limps along or falls back automatically without the user ever noticing a difference. SiteGround’s shared server environment is not one of these lenient setups. An FTP client configured for active mode, or a client whose passive mode setting reverted after being pointed at a previous host’s more forgiving server, will frequently connect successfully to authenticate but then hang indefinitely the moment it tries to list a directory or begin a file transfer, since that is precisely the step that requires the data channel active mode cannot reliably establish. This specific symptom, connects fine, authenticates fine, then hangs or times out exactly when listing files or starting a transfer, is one of the clearest fingerprints of an active-versus-passive mode mismatch rather than any deeper server-side problem.
Every major FTP client, FileZilla, Cyberduck, WinSCP, and the FTP functionality built into editors like Dreamweaver, includes a passive mode setting, and confirming it is explicitly enabled, rather than assuming a default setting is already correct, is the single highest-value check to make before any deeper troubleshooting on a fresh SiteGround connection. In FileZilla specifically, this setting lives under Edit, then Settings, then Connection, then FTP, where the transfer mode should be set to Passive rather than Active or the client’s automatic detection mode, since automatic detection has been reported to occasionally guess wrong specifically against SiteGround’s server configuration.
For anyone using an FTP client without an obvious, dedicated passive mode toggle, a quick way to confirm which mode is actually in use during a connection attempt is checking the client’s own connection log, which every serious FTP client provides in some form, since the log shows the exact PASV or PORT command being issued during the connection handshake, PASV indicating passive mode and PORT indicating active mode. Seeing a PORT command in the log against a SiteGround connection that is hanging or timing out is close to definitive confirmation that switching the client’s transfer mode setting to passive will resolve the issue without needing to investigate anything further on the server side, saving a round of unnecessary back and forth with support over a setting that was entirely within the client’s own control the whole time.
The 4-minute idle timeout nobody can disable
SiteGround’s own documentation confirms directly that the FTP timeout on shared servers cannot be changed by the customer under any circumstance, on any plan tier, and is fixed at a relatively short interval, with SiteGround’s own support material citing roughly 4 minutes of inactivity before a session is automatically terminated. This is a deliberate server-side policy decision aimed at protecting shared server resources from connections left open indefinitely, rather than a bug or a misconfiguration specific to any individual account, and no client-side setting or support ticket will change this fixed limit on shared hosting, regardless of plan tier or account tenure.
It is worth understanding why SiteGround enforces this specific limit so strictly rather than following a more permissive industry norm, since context here helps set realistic expectations about what a support ticket can and cannot resolve. Shared hosting, by definition, runs many customer accounts on the same physical server, and every open connection, including an idle FTP session doing nothing, consumes a small amount of server resources simply by existing. A hosting provider running thousands of shared accounts per server has a strong operational incentive to aggressively close idle connections rather than let them accumulate indefinitely, since an accumulation of forgotten, idle FTP sessions across thousands of accounts could meaningfully degrade server performance for everyone sharing that infrastructure. This is precisely the kind of tradeoff that explains why a fixed, non-negotiable idle timeout exists on shared hosting in a way it typically would not on a dedicated server or a VPS the customer fully controls.
The practical consequence is that any workflow leaving an FTP connection idle for more than a few minutes between actions, a common pattern for anyone using an editor’s built-in FTP browser while writing or editing code between file saves, will experience the connection silently dying and needing to reconnect, which shows up as a stall, a hang, or an outright timeout error depending on the specific client’s own handling of a server-terminated session. This is the exact pattern reported repeatedly by users of editors like Dreamweaver that maintain a persistent FTP session in the background rather than opening a fresh connection for each individual file operation, since a persistent session is exactly the kind of connection SiteGround’s 4-minute idle policy is designed to terminate.
The most reliable fix available on the client side is enabling FTP keepalive commands, a setting most modern FTP clients support specifically to address exactly this kind of server-enforced idle timeout, where the client periodically sends a lightweight command to the server during otherwise idle periods, resetting the idle timer before it has a chance to expire. In FileZilla, this option sits in the same Connection settings area as the passive mode toggle, and enabling it resolves the majority of reported stalling and disconnection complaints from users migrating to SiteGround from a host with a longer or non-enforced idle timeout.
It is worth setting realistic expectations about what keepalive commands can and cannot fix, since they address the idle-timeout symptom specifically without changing the underlying server policy in any way. Keepalive commands work by preventing a connection from ever becoming idle long enough to trigger the timeout in the first place, essentially tricking the server into continuously seeing recent activity even when the human user at the keyboard is not actively transferring files. This works well for a connection that stays open through natural pauses in an editing session, but it does nothing to help a connection that is deliberately closed and needs to be reopened, such as a laptop going to sleep between work sessions, since keepalive only functions while the connection itself remains technically open and active in the background.
For workflows that cannot tolerate any idle period at all, switching from an editor’s built-in FTP auto-upload feature to a dedicated FTP client with a properly configured keepalive setting, and manually uploading in batches rather than relying on an always-connected background session, sidesteps the limitation entirely rather than fighting against a fixed server policy that will never change regardless of how the client is configured. A workflow built around periodic, deliberate batch uploads, rather than a continuously open connection reacting to every individual file save, is also simply a more robust habit generally, since it reduces the number of individual connection attempts that could each independently fail due to a momentary network hiccup, consolidating risk into fewer, more easily retried transfer sessions instead of many small, individually fragile ones.
Related comparisons on this site:
1. Email stopped receiving messages after changing nameservers on Bluehost
2. SSL certificate shows not secure after renewal on Hostinger
3. Cloudways vs SiteGround: cloud hosting compared
4. Hosting account exceeded inode limit
5. Hosting for Mailcow self hosted email
More hosting intelligence
The 421 "too many connections" error and its actual cause
SiteGround limits each individual IP address to a maximum of 8 simultaneous FTP connections at a time, and exceeding this limit produces a 421 error citing too many connections from the client’s IP. This error confuses people because it sounds like it should require deliberately opening eight separate FTP sessions to trigger, which most individual users assume they are nowhere near doing, when in practice a single FTP client’s own default settings are frequently the actual cause without any deliberate action on the user’s part.
Modern FTP clients, including FileZilla by default, are configured to open multiple simultaneous connections automatically to speed up transfers involving many small files, since parallel transfers complete faster than a strictly sequential, one-file-at-a-time approach for a large batch of files. A client defaulting to a higher simultaneous connection count than SiteGround’s 8-connection ceiling, particularly if that default was tuned against a more permissive previous host, will trigger the 421 error specifically when transferring a large number of files at once, even though the exact same client configuration worked without any issue on the previous hosting provider.
This is worth understanding as a specific migration hazard rather than a random inconsistency, since it explains a genuinely confusing pattern some users report: small, simple transfers work perfectly fine on SiteGround, while large batch uploads, such as deploying an entire WordPress theme or plugin directory containing hundreds of individual files, trigger the 421 error reliably. The connection count that causes the problem only gets exercised at all once a transfer is large enough to actually benefit from parallel connections in the first place, which is exactly why a smaller test transfer during initial setup can pass cleanly while a subsequent full site migration or theme deployment runs straight into the limit later, creating a false sense that the connection was properly validated before the actual problem transfer even began, when in reality the earlier successful test simply never exercised the specific condition that later triggers the failure.
The fix is adjusting the client’s own maximum simultaneous connections setting to stay safely under SiteGround’s 8-connection limit, commonly set to 5 or 6 as a safety margin rather than the maximum allowed value, since other processes or a second device also connecting under the same IP address can otherwise still push the combined total over the ceiling even when a single client instance is correctly configured. In FileZilla, this setting is found in the Site Manager under the specific site’s Transfer Settings tab, where limiting the number of simultaneous connections resolves the 421 error in the great majority of reported cases.
If the error persists after adjusting this setting, existing stuck connections from a previous session that never properly closed can sometimes remain counted against the limit until they naturally expire, and SiteGround’s own Site Tools interface provides a way to view and manually terminate any lingering FTP sessions still counted against the account. This scenario is more common than it might seem, since an FTP client that crashes, loses network connectivity abruptly, or has its host machine put to sleep mid-transfer does not always get the opportunity to properly close its connections on the way out, leaving the server-side counter still reflecting connections that the client itself has already forgotten about entirely. A manual reset through Site Tools clears this discrepancy immediately, without needing to wait for the server’s own eventual timeout to release the stale connection count on its own.
For an agency deploying to multiple client sites hosted on SiteGround, standardizing the maximum simultaneous connections setting across every team member’s FTP client configuration, rather than leaving it at whatever each individual client’s own default happens to be, prevents this specific error from recurring unpredictably across different team members working on different projects, each potentially rediscovering the same fix independently the first time they personally run into the 421 error on a large deployment, a small amount of preventable friction that a single shared configuration standard eliminates entirely for the whole team going forward.
The DNS trap: connecting to the old host without realizing it
For anyone who switched to SiteGround as part of a broader migration from a previous host, rather than starting a brand new site directly on SiteGround, there is a timing-specific trap worth checking before assuming anything about SiteGround’s own FTP configuration is the actual problem. If the FTP client is configured to connect using the domain name itself, rather than the account’s specific server IP address, and DNS has not yet fully propagated to reflect the new hosting location, the client may still be silently connecting to the previous host’s server, which explains behavior that looks exactly like an FTP problem but is not actually related to SiteGround’s configuration at all.
This trap is particularly insidious because the symptoms it produces are genuinely indistinguishable, from the user’s own perspective, from an actual SiteGround-side FTP problem. A connection attempt against the previous host, which may have already been partially decommissioned, had its own account suspended as part of the migration process, or is simply under different resource constraints than it was before, can time out, hang, or behave erratically in ways that look exactly like the passive mode or connection limit problems described earlier in this article, with no obvious signal distinguishing the two scenarios apart from the exact server actually being reached. Someone experiencing this specific trap could spend considerable time adjusting passive mode settings, connection limits, and keepalive commands in their FTP client, none of which will have any effect at all, since the client throughout this entire troubleshooting process was never actually reaching SiteGround’s servers to begin with.
This is precisely why SiteGround’s own troubleshooting documentation specifically recommends connecting using the account’s dedicated IP address rather than the domain name during the period immediately following a migration, since the IP address bypasses DNS entirely and guarantees the connection reaches the correct, current server regardless of how far DNS propagation for the domain itself has progressed. This account-specific IP address is available directly in Site Tools under Site, then Site Information, or through the same Server Details section that lists other account-specific connection information, and using it during the migration window removes any ambiguity about which server an FTP client is actually reaching at any given moment during the transition period.
A useful diagnostic habit during any hosting migration is deliberately testing both connection methods, the domain name and the account’s direct IP address, and comparing whether they behave differently. If connecting via IP address works reliably while connecting via domain name times out, hangs, or behaves inconsistently, that difference is strong confirmation that DNS propagation, rather than SiteGround’s server configuration itself, is the actual variable still in flux, and the fix is simply waiting for propagation to complete rather than troubleshooting FTP settings that were never actually the problem, a distinction that can save hours of unproductive settings adjustments during an already time-pressured migration window when the client is understandably eager to see the new site fully functional as quickly as possible.
For a migration handled by an agency on behalf of a client, building this specific check into the standard migration workflow, testing FTP by IP address first and only troubleshooting the domain-based connection separately once DNS propagation is independently confirmed complete through a public DNS lookup tool, avoids wasting time investigating FTP client settings during a window when the actual variable in flux is entirely outside the FTP client’s control, and gives the team a clean, defensible answer if a client asks why FTP briefly behaved unpredictably during the migration window itself. This distinction between an FTP problem and a DNS propagation window disguised as an FTP problem is one of the more valuable pieces of process knowledge to document once and apply consistently across every future migration, rather than rediscovering the same confusion independently on each new client project.
Finding FTP credentials in Site Tools rather than cPanel
SiteGround does not use cPanel at all, relying instead on its own proprietary control panel called Site Tools, which organizes account management differently enough from cPanel’s familiar layout that anyone migrating from a cPanel-based host can genuinely struggle to locate basic settings like FTP credentials purely because they are looking in the wrong conceptual location based on habits built on a different panel entirely.
This is worth naming explicitly rather than assuming it is a minor inconvenience, since the overwhelming majority of shared hosting providers in the market do use cPanel, or a close variant of it, which means most existing tutorials, community forum answers, and even muscle memory built up over years of managing other hosting accounts simply does not transfer directly to SiteGround. Searching for generic phrases like “where are my FTP credentials in cPanel” will return results that are actively unhelpful for a SiteGround account specifically, since the entire navigation structure being described in those results does not exist on SiteGround at all. Recognizing this early, and specifically searching for SiteGround’s own documentation and terminology rather than generic cPanel-focused guidance, saves considerable frustration during the initial learning curve of a new SiteGround account.
In Site Tools, FTP accounts and their credentials live under Site, then FTP Accounts, a section that lists every FTP account associated with the site along with the ability to create new ones or reset the password on an existing one, since SiteGround does not display existing plaintext passwords for security reasons and instead requires setting a new password if the original was not saved somewhere secure at the time of account creation. This security-conscious design choice, storing passwords in a way that prevents even the account owner from later viewing them in plaintext through the panel itself, is standard practice across most modern hosting platforms, but it specifically means that losing track of an FTP password requires a deliberate password reset rather than simply looking the existing value up again, a workflow difference worth anticipating before it becomes an unexpected blocker during an urgent deployment.
The FTP hostname itself, along with the account’s dedicated IP address referenced in the previous section, is available through the kebab menu next to the domain in the Websites section of the Client Area, under Website Settings, then Server Details, a location that is not obviously related to FTP at first glance but is specifically where SiteGround consolidates the connection details most relevant to any external tool connecting to the account, FTP included. This same Server Details section also surfaces other connection information useful beyond FTP specifically, including database connection details and SSH access information for accounts with that feature enabled, making it worth bookmarking as a general reference point for any external tool needing to connect to a SiteGround-hosted site, rather than a location relevant only to the specific FTP troubleshooting this article covers.
For anyone setting up a new FTP account rather than troubleshooting an existing one, Site Tools also allows scoping a new FTP account’s access to a specific subdirectory rather than granting access to the entire hosting account, a genuinely useful security practice when providing FTP access to an external contractor or a specific team member who only needs to work within one particular site’s files rather than every site hosted under the same account, reducing the blast radius of any single compromised credential considerably. This scoped access option is set at the moment of creating the new FTP account within the same FTP Accounts section, and applying it as a default practice, rather than only using the account’s main, full-access FTP credentials for every purpose, meaningfully limits the potential damage from a single set of compromised credentials affecting only the scoped directory rather than the entire hosting account.
Sources and references consulted: active vs passive FTP, SiteGround shared hosting, Dreamweaver FTP, FileZilla connection test, common FTP errors, SiteGround FTP timeout policy, FTP session terminated, SiteGround FTP connection limits, FileZilla Site Manager, account IP address, Site Tools overview, whatsmydns.net, mxtoolbox.com, siteground.com, FTP account security.
