Fix EAI_NONAME Error in FileZilla and FTP

What does EAI_NONAME mean in FileZilla?

EAI_NONAME means the name-resolution stage failed: FileZilla could not obtain a usable network address for the hostname it was given. If the client stops here, the FTP or SFTP service may not have seen any connection attempt at all.

If FileZilla stops while resolving the host, changing the FTP password cannot affect that stage. A bad password is tested later. The same applies to directory permissions, passive FTP mode, and most server-side account settings.

A representative FileZilla log at this point may look roughly like this:

Status: Resolving address of ftp.example.com
Error: Could not resolve host / EAI_NONAME

The exact wording varies with FileZilla version and operating system. The diagnostic clue is the stage: the failure appears while FileZilla is resolving the address, before a line that shows a connection to an IP and port.

Take the exact hostname from FileZilla and query it outside the client:

nslookup ftp.example.com

On Linux or macOS, dig gives a more DNS-oriented view:

dig ftp.example.com

On Linux, it is also useful to ask the normal system resolver:

getent hosts ftp.example.com

dig and nslookup primarily show what DNS says. getent hosts follows the system's name-service configuration and may also reflect local sources such as /etc/hosts. That difference becomes valuable when FileZilla fails but a direct DNS query succeeds.

If the DNS query returns the expected IPv4 or IPv6 address, basic DNS resolution is working from that resolver's point of view. NXDOMAIN means that resolver considers the requested name nonexistent. A timeout means the resolver did not answer; it does not automatically mean that the hostname itself is missing.

If the message changes from EAI_NONAME to a timeout after you correct the Host value, DNS is no longer the first failed stage. That change is useful evidence. The client got further.

Is the Host field in FileZilla correct?

Check the exact Host value before changing anything else. A typo, copied path, old server name, trailing punctuation, or saved Site Manager profile can produce a name-resolution failure even when the FTP server itself is healthy.

For troubleshooting, reduce the value to a plain hostname or IP address. FileZilla can accept protocol-prefixed connection strings in some contexts, but a bare hostname is easier to compare directly with nslookup, dig, or the system resolver.

Host, username, password and port are separate parameters

A hosting panel may show all connection details together, but they should not all end up in the Host field:

• Host: ftp.example.com or another server hostname.
• Username: the FTP or SFTP account.
• Password: the account password.
• Port: the port configured for FTP, FTPS, or SFTP.

A user sometimes copies a browser address such as https://example.com/account/ftp and pastes the whole string into FileZilla. That is a web URL, not an FTP hostname. Strip the value down and test the name itself.

Also check for characters that are hard to notice when copied from email or a support ticket: trailing spaces, commas, periods, line breaks, or a username attached to the hostname. If the value looks suspicious, paste it into a plain-text editor and retype it manually.

Do not assume ftp.example.com exists

A working website does not prove that ftp.example.com exists. The root domain and the FTP endpoint can use completely different DNS names.

example.com       203.0.113.10
ftp.example.com   NXDOMAIN

Here the website is fine. The FTP subdomain is not. Check the actual connection details from the hosting provider instead of inventing an ftp. hostname because it looks conventional.

Is FileZilla still using an old Site Manager hostname?

Server migrations produce another easy-to-miss case. The website has already moved, DNS has been updated, and the user even tests the new server successfully with Quickconnect. The next day they open a saved Site Manager entry and EAI_NONAME is back.

Open the saved site and compare its Host value with the current connection details. Look for an old provider hostname such as:

old-node12.host.example

If that hostname was retired after migration, clearing DNS cache will not repair it. Update the saved entry itself.

The same check applies to bookmarks or duplicated Site Manager profiles. FileZilla may be doing exactly what it was configured to do; the stale value is simply hidden in a saved profile.

Short hostnames can depend on a DNS search suffix

A Host value such as ftpserver may work inside a corporate network because the operating system automatically tries a search suffix and resolves something like ftpserver.company.local. The same short name can fail immediately on a home connection where that suffix does not exist.

When possible, test the full hostname instead of a short local alias:

ftpserver.company.local

If the full name works but the short name does not, the problem is resolver configuration rather than FTP.

After correcting the Host value, reconnect and watch the FileZilla log. Once the client displays a resolved IP or moves to a connection attempt, you have passed the EAI_NONAME stage.

Does the FTP hostname actually exist in DNS?

If the exact hostname from FileZilla does not return a usable address, inspect the DNS record for that name. The hostname may be absent, point to an old server, or exist as a CNAME whose target is broken.

Query the exact FTP hostname

If FileZilla uses ftp.example.com, query ftp.example.com. Checking only example.com answers a different question.

Windows:

nslookup ftp.example.com

PowerShell:

Resolve-DnsName ftp.example.com

Linux or macOS:

dig ftp.example.com

A usable result may be an A record, an AAAA record, or a CNAME that ultimately leads to an address. An FTP hostname does not need both IPv4 and IPv6. If a valid A record exists, the absence of an AAAA record alone is not a failure.

Compare the website hostname and FTP hostname separately

dig example.com
dig ftp.example.com

If example.com returns an address but ftp.example.com returns NXDOMAIN, the problem is limited to the FTP name. Check whether that subdomain is supposed to exist or whether the provider expects a different server hostname.

Some hosting services provide a hostname such as node17.host.example for FTP, FTPS, or SFTP. Creating ftp.example.com is optional unless the hosting configuration specifically expects it. Use the endpoint that is actually documented for the account.

A CNAME can exist while its target is broken

A DNS name can appear to be configured and still fail because it aliases another hostname that no longer resolves. A representative case looks like this:

ftp.example.com.          300 IN CNAME node15.host.example.
node15.host.example.      NXDOMAIN

The ftp.example.com record exists, but the chain ends at a dead target. Query both names:

dig ftp.example.com
dig +short ftp.example.com
dig node15.host.example

If the CNAME target no longer has an address, repair the target or point the FTP hostname at the current server. Adding another cache flush on the client will not help.

Distinguish NXDOMAIN, empty answers and resolver timeouts

Check the authoritative DNS when public resolvers disagree

If one resolver returns the new server and another returns an old address, first identify the authoritative name servers for the domain:

dig NS example.com

On Windows, an equivalent starting point is:

nslookup -type=NS example.com

Then query one of the authoritative servers directly. Replace the placeholder server below with an actual authoritative name server returned for the domain:

dig @ns1.dns-provider.example ftp.example.com A
dig @ns1.dns-provider.example ftp.example.com AAAA

If the authoritative server already returns the correct record but a recursive resolver still returns an older value, cached DNS is a reasonable explanation. If the authoritative server itself returns the wrong value, flushing a workstation will achieve nothing; fix the DNS zone first.

TTL explains some temporary disagreement between resolvers

Suppose ftp.example.com previously pointed to 192.0.2.20 and has just been changed to 203.0.113.10. Recursive resolvers that cached the old answer can continue using it until that cached TTL expires.

A practical comparison might look like this:

System DNS        192.0.2.20
1.1.1.1           203.0.113.10
8.8.8.8           203.0.113.10
Authoritative DNS 203.0.113.10

Here the zone itself is already correct. The outlier is the resolver used by the affected computer or network.

Always query the hostname FileZilla actually uses. Testing the website domain can make a broken FTP record invisible.

Can FileZilla connect to the server by IP address?

Testing the intended server by IP is one of the fastest ways to separate hostname resolution from reachability. If FileZilla fails on the hostname but reaches the same endpoint by IP, return to DNS instead of changing FTP credentials.

Get the server address from the hosting or VPS panel, provider documentation, or another authoritative source for that service. A website lookup may return a CDN, reverse proxy, or web-server address that is not the FTP endpoint.

Keep the protocol and port unchanged and replace only Host:

203.0.113.10

If the IP works but the hostname fails

A result like this narrows the original failure sharply:

ftp.example.com   EAI_NONAME
203.0.113.10      connection reaches the selected port

The IP test confirms that this client can reach at least the tested endpoint with the selected protocol and port. It does not prove that every FTP, FTPS, or SFTP setting is correct.

If the server then asks for credentials, DNS was the blocker for the hostname connection. Stop resetting passwords and fix the name.

If neither IP nor hostname works

The IP test can expose a second problem that was hidden behind EAI_NONAME:

• Connection timed out means the TCP connection did not complete.
• Connection refused means the destination rejected the requested port or no service is listening there.
• Authentication failed means the connection already reached the login stage.

That new error is not a failed DNS test. Read it on its own terms.

Use an IP as a diagnostic test, not automatically as a permanent hostname replacement

FTPS certificates are normally issued for hostnames. Connecting directly to an IP can therefore create a certificate-name mismatch even when the server is otherwise correct. With SFTP, using a different address may create a different SSH host-key entry.

IPv4 and IPv6 can produce different connection behavior

If the hostname has both A and AAAA records, compare them:

dig A ftp.example.com
dig AAAA ftp.example.com

PowerShell:

Resolve-DnsName ftp.example.com -Type A
Resolve-DnsName ftp.example.com -Type AAAA

A broken IPv6 route or firewall usually produces a reachability problem rather than EAI_NONAME because the hostname still resolves. That distinction matters. Do not blame IPv6 merely because an AAAA record exists.

If a direct IPv4 test works while the hostname resolves to both IPv4 and IPv6 and the normal connection still stalls, test reachability on both address families. The original EAI_NONAME may already be solved, with an IPv6 network problem now exposed underneath it.

Why does nslookup work while FileZilla still shows EAI_NONAME?

If nslookup returns an IP but FileZilla still reports EAI_NONAME, do not assume FileZilla and nslookup are resolving the same name through the same path. Verify the exact Host value and then compare direct DNS with the operating system's normal resolver.

This is where the troubleshooting gets more interesting. A successful nslookup proves that a DNS server answered the query you typed. It does not prove that FileZilla is using that exact hostname, that a saved profile was updated, or that the system resolver sees the same result.

Confirm the hostname in the active FileZilla profile

Copy the Host value from the exact Site Manager entry or Quickconnect session that fails. Do not type what you think the value is. Compare the literal string.

A migration can leave two profiles:

Quickconnect:
new-node.host.example

Site Manager:
old-node.host.example

nslookup new-node.host.example can work perfectly while FileZilla continues trying the old saved name. In that case DNS is behaving correctly; the client configuration is stale.

Compare direct DNS with the system resolver

On Linux:

dig ftp.example.com
getent hosts ftp.example.com

If dig returns an IP but getent hosts fails or returns something different, inspect /etc/hosts, Name Service Switch configuration, local caching services, VPN DNS, and resolver settings.

On Windows, query DNS and then ask the .NET system resolver:

nslookup ftp.example.com

[System.Net.Dns]::GetHostAddresses("ftp.example.com")

If the DNS query succeeds but the application-level resolver fails, the discrepancy is more relevant to FileZilla than another successful public DNS lookup.

On macOS, compare a DNS-oriented lookup with the system name service:

dig ftp.example.com
dscacheutil -q host -a name ftp.example.com

A hosts entry may make the system resolver disagree with nslookup

Direct DNS tools and application lookups do not always consult identical sources. For example, the public DNS may return:

ftp.example.com   203.0.113.10

while a local hosts file still contains:

192.0.2.20 ftp.example.com

That usually sends the application to the wrong IP rather than producing EAI_NONAME, but it proves why a successful nslookup does not end the investigation.

Check whether the Host value is an internationalized domain

If the server hostname contains non-ASCII characters, verify the exact hostname FileZilla and the resolver are using. Internationalized domain names are represented in DNS using an ASCII-compatible form, commonly seen with an xn-- prefix.

This is not a common EAI_NONAME cause, so do not start here. It becomes relevant when the hostname contains national characters, was copied from a formatted source, or resolves differently when entered in its ASCII form.

Once the system resolver returns the expected address for the exact hostname stored in FileZilla, retry the client. If the log now shows a connection to an IP, EAI_NONAME has been cleared and the next message belongs to the next stage.

Can CNAME, IPv6 or split DNS affect FileZilla hostname resolution?

Yes, but these are second-line checks after the basic hostname test. A broken CNAME target can prevent a usable address from being returned, split DNS can intentionally give different answers on different networks, and IPv4/IPv6 can change how the connection proceeds after resolution.

Broken CNAME chain

Consider this DNS configuration:

ftp.example.com.       CNAME node8.provider.example.
node8.provider.example NXDOMAIN

The visible FTP hostname exists as a CNAME, but the chain does not finish at an address. Query the alias and its target separately:

dig ftp.example.com
dig node8.provider.example

Repair the CNAME target or point the FTP hostname at a current endpoint. Client-side DNS cache flushing cannot fix a broken authoritative chain.

Split DNS can make the same hostname correct on one network and nonexistent on another

Corporate networks sometimes publish different DNS answers internally and externally. For example:

Office DNS:
ftp.example.com   10.10.0.25

Public DNS:
ftp.example.com   NXDOMAIN

Inside the office, the private address is intentional. Outside the office, the hostname does not exist. The reverse setup is also possible: public DNS works while an internal resolver still carries an obsolete zone.

If FileZilla works at home but not through a company VPN, or works in the office but not over mobile internet, compare the DNS answers before editing records. Different does not automatically mean broken.

IPv6 usually changes reachability, not whether the name exists

A hostname may return both:

A       203.0.113.10
AAAA    2001:db8::10

If both records are valid but the IPv6 path is broken, the client may time out or fall back depending on the operating system and network stack. That is normally not EAI_NONAME because DNS has already returned addresses.

Use separate record queries when the symptom changes after DNS starts working:

dig A ftp.example.com
dig AAAA ftp.example.com

Then test the expected service on the address family that should be reachable. Do not delete a correct AAAA record merely because an unrelated FileZilla error appeared; confirm the failed path first.

DNS changes after migration can expose all three problems at once

A migration can leave a messy combination: the root domain has moved, ftp.example.com still CNAMEs to the old provider, one resolver has cached the previous answer, and Site Manager still contains the old server hostname. Randomly clearing caches can make the situation look inconsistent from one test to the next.

Work from the source outward:

1. Confirm the current endpoint in the hosting or VPS panel.
2. Confirm the authoritative DNS record or CNAME chain.
3. Compare public recursive resolvers.
4. Compare the affected system resolver.
5. Verify the active FileZilla Host value.

That order prevents a stale FileZilla profile from being mistaken for a DNS propagation problem, or a broken CNAME from being blamed on the workstation.

Is the DNS problem only on one computer or network?

If EAI_NONAME occurs on only one device or network, the public DNS record may already be correct. Compare the same hostname from another device, another network, and another resolver before modifying the domain's DNS zone.

Compare multiple resolvers without changing the system configuration

On Windows:

nslookup ftp.example.com
nslookup ftp.example.com 1.1.1.1
nslookup ftp.example.com 8.8.8.8

If public resolvers return the expected IP but the normal system DNS returns NXDOMAIN or an old address, the investigation moves toward the local network, ISP resolver, VPN, or cache.

Do not switch every device to a public resolver just because the test works. First find out why the current resolver gives a different answer.

Use another device and another network to locate the boundary

A concrete result set is more useful than a generic “try another device”:

That pattern points toward the resolver path used by the home network. Reinstalling FileZilla on the PC would not address it.

Another pattern tells a different story:

VPN and corporate DNS can move the boundary

VPN software can install different DNS servers, search domains, or routing rules while the tunnel is active. A corporate resolver may also hold a private zone for the FTP hostname.

Where company policy allows, compare one lookup with the VPN connected and one without it. Record the answers. If the hostname resolves to a private IP over VPN and a public IP without VPN, that may be intentional split DNS. If it resolves only in one state, the network design or resolver configuration needs to be understood before anything is changed.

The browser is a poor control test when it opens a different hostname. Always compare the exact FTP or SFTP Host value.

How do you clear a stale DNS cache on Windows, macOS and Linux?

Flush a local DNS cache when you have evidence that the current DNS record is correct but the affected system is still using an older or failed result. A cache flush cannot create a missing DNS record and cannot repair a broken CNAME.

A good reason to flush looks like this:

Public resolver:
ftp.example.com   203.0.113.10

Affected system:
ftp.example.com   192.0.2.20

Now there is something specific to clear.

Windows

Run:

ipconfig /flushdns

Then repeat the lookup:

nslookup ftp.example.com

PowerShell can show more detail:

Resolve-DnsName ftp.example.com

For an application-oriented check, the .NET resolver is useful:

[System.Net.Dns]::GetHostAddresses("ftp.example.com")

Do not stop at “Successfully flushed the DNS Resolver Cache.” The result that matters is whether the affected computer now resolves the hostname to the expected address.

Linux

Linux resolver stacks vary. On systems using systemd-resolved:

resolvectl query ftp.example.com
resolvectl flush-caches

Check the active DNS configuration:

resolvectl status

And compare the normal Name Service Switch path:

getent hosts ftp.example.com

If the system uses dnsmasq, NetworkManager caching, another local resolver, containers with their own DNS settings, or a manually managed /etc/resolv.conf, the correct reset procedure may differ. Identify the active resolver before restarting random services.

macOS

Start by checking both DNS and the system name service:

dig ftp.example.com
dscacheutil -q host -a name ftp.example.com

macOS cache behavior and reset commands vary across releases, so match any cache-reset procedure to the installed version rather than copying an old command blindly. Reconnecting the network and repeating the resolver checks is a useful low-risk diagnostic step.

Once the local answer matches the expected DNS record, retry FileZilla. If EAI_NONAME remains, move from cache flushing to resolver-path and FileZilla-profile checks instead of repeating the same command.

Can the hosts file, VPN or security software affect FileZilla DNS?

Yes. FileZilla relies on the operating system's networking environment, so a local hosts override, VPN resolver, corporate DNS policy, or DNS-filtering product can make the application see a different result from a direct public DNS query.

Check the hosts file when system resolution and DNS disagree

Windows:

C:\Windows\System32\drivers\etc\hosts

Linux and macOS:

/etc/hosts

Look for the affected hostname:

192.0.2.20 ftp.example.com

A stale hosts entry usually creates a wrong-IP connection problem rather than EAI_NONAME because the hostname still resolves locally. It matters here because applications and direct DNS tools can appear to disagree.

After a server migration, this kind of forgotten override is worth checking. Public DNS can already point to the new server while the operating system keeps sending FileZilla to the old one.

On Linux, compare:

dig ftp.example.com
getent hosts ftp.example.com

If the results differ, investigate local name-service rules before editing public DNS.

Can split DNS make FileZilla resolve a different address?

Yes. A VPN or corporate network can intentionally return a private server address while public DNS returns something else.

Corporate DNS:
ftp.example.com   10.10.0.25

Public DNS:
ftp.example.com   203.0.113.10

Neither answer is automatically wrong. The question is which endpoint the client is supposed to use from that network.

If FileZilla works only while the VPN is connected, the hostname may be private. If it fails only on VPN, the corporate resolver may have a stale or incomplete zone. Compare the actual results before changing settings.

Security software can interfere with DNS without blocking FTP directly

Endpoint-security products, DNS filters, parental-control tools, and enterprise network agents can intercept hostname resolution. Firewalls, on the other hand, can allow DNS to succeed but block the FTP or SFTP TCP port later.

• If the hostname does not resolve, inspect DNS filtering and resolver behavior.
• If the hostname resolves but the port cannot be reached, inspect firewall and network filtering.

Where a temporary test is allowed, change one component and immediately repeat the same hostname lookup. Do not disable the VPN, firewall, antivirus, and DNS filter simultaneously. If FileZilla suddenly starts working after four changes, you have learned very little.

Check which DNS servers the operating system is actually using

Windows:

ipconfig /all

Linux with systemd-resolved:

resolvectl status

These commands can reveal a resolver supplied by a VPN, router, corporate interface, or another network adapter. A workstation with Ethernet, Wi-Fi, VPN, and virtual machine adapters may not be querying the server you expect.

If the configured resolver differs from the one you tested manually, compare both. That gap often explains why a public nslookup succeeds while the application still behaves differently.

What if EAI_NONAME disappears but FileZilla still cannot connect?

If FileZilla starts resolving the hostname but then reports a timeout, refusal, TLS error, or authentication failure, EAI_NONAME has been cleared. Read the new message as a new stage of the connection.

A representative transition can look like this:

Status: Resolving address of ftp.example.com
Status: Connecting to 203.0.113.10:21...
Error: Connection refused

Exact wording varies, but the key evidence is the IP and port in the log. DNS is already out of the way here.

Check the selected protocol and port

FTP, FTPS, and SFTP are not interchangeable:

• FTP commonly uses TCP port 21 for its control connection.
• SFTP runs over SSH and commonly uses port 22.
• Implicit FTPS is often configured on port 990.

Those are defaults, not rules. A hosting provider or VPS administrator can use another port. Always compare FileZilla with the actual server configuration.

Windows PowerShell:

Test-NetConnection ftp.example.com -Port 21

For SFTP:

Test-NetConnection ftp.example.com -Port 22

Linux or macOS:

nc -vz ftp.example.com 21
nc -vz ftp.example.com 22

If hostname resolution succeeds but the TCP test fails, do not return to DNS unless new evidence points there.

Use Site Manager when protocol details need to be explicit

Quickconnect is convenient for a simple test, but Site Manager makes the selected protocol, encryption mode, host, port, and logon type visible in one place. That helps when a user has been switching between FTP, FTPS, and SFTP while trying to fix EAI_NONAME.

It also prevents a subtle troubleshooting error: testing the new Host in Quickconnect and then reconnecting with an old saved profile that has a different protocol or port.

Read the next FileZilla error by stage

Passive FTP mode belongs later in the troubleshooting chain

Passive-mode problems normally appear after FileZilla has resolved the hostname and established the FTP control connection. Switching active and passive mode cannot repair a name that DNS does not resolve.

Directory permissions are even further down the chain: the server cannot deny access to public_html or trigger a failure to retrieve the FTP directory listing until FileZilla has actually reached the server and authenticated.

Once the error changes, let it change the investigation. Continuing to flush DNS after FileZilla is already talking to an IP only wastes time.

What is the fastest diagnostic sequence for EAI_NONAME?

Work in a fixed order: Host, DNS, external resolver, server IP, system resolver, TCP port, then protocol and authentication. Stop at the first failed stage instead of changing several layers at once.

One migration scenario shows why the order matters. The website has moved to a new server, authoritative DNS already contains the new address, an ISP resolver still has an older cached answer, and FileZilla Site Manager still stores a provider hostname that has been retired. Clearing the workstation cache first may change nothing because two independent stale values remain.

Check the active Host. Check DNS. Compare resolvers. Check the system resolver. Then test the endpoint. One failed test, one conclusion.

For EAI_NONAME, the decisive question remains simple: does the exact hostname FileZilla is using resolve through the affected system to the server address it should use? Once the answer is yes and the log advances to an IP and port, stop troubleshooting EAI_NONAME and follow the next error instead.