The Server Network Address Cannot Be Reached or Does Not Exist (Error 1418)

You are halfway through wiring up a mirror or an Availability Group, the wizard or the SET PARTNER statement stops dead, and the only thing you get back is 1418. It is the least specific error in high availability, and it has exactly one useful property: the server error log knows what the message will not tell you.

Everything below is from a real pair of instances, a SQL Server 2025 instance with a certificate authenticated mirroring endpoint on TCP 5022 and a second instance it was pointed at. Where a check needs a domain or a Windows Firewall rule to demonstrate properly, it is marked as documented rather than reproduced.

The Same Message for Four Different Faults

Four deliberately different faults were put in front of the same statement, and the reply was byte for byte the same each time apart from the address. A right host with a wrong port, an address that silently drops the packets, a name that does not resolve, and a port that is genuinely listening but belongs to something that is not a mirroring endpoint:

Msg 1418, Level 16, State 1, Server HPAI01, Line 2
The server network address "TCP://HPAI01:5023" can not be reached or does not exist. ...

Msg 1418, Level 16, State 1, Server HPAI01, Line 2
The server network address "TCP://192.0.2.10:5022" can not be reached or does not exist. ...

Msg 1418, Level 16, State 1, Server HPAI01, Line 2
The server network address "TCP://sqlnode2.corp.invalid:5022" can not be reached or does not exist. ...

Msg 1418, Level 16, State 1, Server HPAI01, Line 2
The server network address "TCP://localhost:14332" can not be reached or does not exist. ...

That is why 1418 has a reputation for being unfixable. People change one thing, run it again, get the identical message, and conclude the change did nothing. The message cannot tell you whether it did. Microsoft’s own guidance on the address format is Specify a Server Network Address on MS Docs, and it is worth two minutes because a surprising share of 1418 is a malformed address rather than a broken network.

The Error Log Names the Fault the Message Hides

Run EXEC xp_readerrorlog 0, 1, N'mirroring' on the instance that raised the 1418, immediately after it raises it. These are the four lines the four attempts above wrote, in the same order, with the date column trimmed:

16:32:34.45 spid73s  Database mirroring connection error 2 'Connection attempt failed with error:
                     '10061(No connection could be made because the target machine actively
                     refused it.)'.' for 'TCP://HPAI01:5023'.
16:33:12.79 spid73s  Database mirroring connection error 2 'Connection attempt failed with error:
                     '11001(No such host is known.)'.' for 'TCP://sqlnode2.corp.invalid:5022'.
16:33:13.52 spid93s  Database mirroring connection error 2 'Connection attempt failed with error:
                     '10060(A connection attempt failed because the connected party did not
                     properly respond after a period of time ...)'.' for 'TCP://192.0.2.10:5022'.
16:33:32.78 spid96s  Database mirroring connection error 4 'An error occurred while receiving
                     data: '24(The program issued a command but the command length is
                     incorrect.)'.' for 'TCP://localhost:14332'.

Four Windows socket codes, four completely different jobs of work. This is the single highest value thing on the page, and it is why the first instruction in the section above is to read the log rather than to change a setting.

Which Line You Have, and Where to Go

Check 1: Is the Endpoint There, and Is It STARTED

Run this on both servers. An endpoint that exists but is STOPPED is the most common cause of the 10061 line, because a stopped endpoint closes its port and the machine then refuses the connection exactly as if no endpoint had ever been created:

SELECT e.name, e.state_desc, e.role_desc, e.connection_auth_desc,
       e.encryption_algorithm_desc, te.port
FROM   sys.database_mirroring_endpoints e
JOIN   sys.tcp_endpoints te ON te.endpoint_id = e.endpoint_id;

name                state_desc  role_desc  connection_auth_desc  encryption_algorithm_desc  port
------------------  ----------  ---------  --------------------  -------------------------  ----
Lab1001b_Mirroring  STARTED     PARTNER    CERTIFICATE           AES                        5022

Three things to read off that row before you move on. state_desc must be STARTED, and ALTER ENDPOINT YourEndpoint STATE = STARTED is the fix. role_desc must allow the job you are asking for, so a PARTNER cannot act as a witness and a WITNESS cannot be a partner. And port is the number you must use in the address, whatever the convention says, because 5022 is only a habit and nothing enforces it. If the query returns no rows at all there is no mirroring endpoint on that instance and that is your answer.

One useful distinction while you are here. If it is your own endpoint that is stopped, you do not get 1418 at all, you get Msg 1486, Level 14, State 44, Database Mirroring Transport is disabled in the endpoint configuration. So a 1418 tells you your local endpoint was up and the problem is at the far end or on the wire between you.

Check 2: Is the Port Actually Listening, From the Other Server

Prove the port is open from the machine that is complaining, not from your desk. Test-NetConnection gives a plain true or false, and Get-NetTCPConnection on the far server proves the listener is really the endpoint:

# From the server that raised 1418, pointed at the partner
Test-NetConnection -ComputerName HPAI01 -Port 5022 -InformationLevel Quiet
Test-NetConnection -ComputerName HPAI01 -Port 5023 -InformationLevel Quiet

# On the partner itself
Get-NetTCPConnection -LocalPort 5022 -State Listen | Select-Object LocalAddress, LocalPort, State

True
False

LocalAddress  LocalPort  State
------------  ---------  -----
::                 5022  Listen
0.0.0.0            5022  Listen

The pair matters more than either result alone. True on the endpoint port and false on a neighbouring port is what a healthy server looks like; false on both usually means the firewall, and true on both means you are talking to something that is not the endpoint you think it is. In the lab the same port returned False the moment the endpoint was set to STOPPED and True again when it was restarted, with no firewall change in between, which is the cleanest demonstration that the endpoint owns the listener. The port reference for everything else SQL Server opens is SQL Server Default Ports, and the longer walk through the test itself is Testing Remote Server Port Connectivity with PowerShell.

Check 3: Does the Far End Actually Let You Connect

An endpoint that is up and reachable will still refuse a partner whose login has no CONNECT on it. With certificate authentication that login is the one the partner’s certificate is mapped to; with Windows authentication it is the other instance’s service account. Check what is granted, on both sides:

SELECT pr.name AS grantee, pe.permission_name, pe.state_desc, e.name AS endpoint_name
FROM   sys.server_permissions pe
JOIN   sys.server_principals pr ON pr.principal_id = pe.grantee_principal_id
JOIN   sys.endpoints e          ON e.endpoint_id   = pe.major_id
WHERE  pe.class_desc = 'ENDPOINT';

-- The grant itself, if it is missing
GRANT CONNECT ON ENDPOINT::YourEndpoint TO [YourPartnerLogin];

grantee                 permission_name  state_desc  endpoint_name
----------------------  ---------------  ----------  ------------------
public                  CONNECT          GRANT       TSQL Default TCP
Lab1001b_partner_login  CONNECT          GRANT       Lab1001b_Mirroring

Before the grant was made, that query returned zero rows for the mirroring endpoint, which is what a missing permission looks like: not an error, an absence. The four built in TSQL endpoints always carry a grant to public, so a mirroring endpoint with no row of its own stands out immediately. Setting up the certificates themselves is covered on MS Docs under Use Certificates for a Database Mirroring Endpoint, and if you are using Windows authentication between domain accounts instead, the thing that silently breaks it is covered in Kerberos vs NTLM.

Check 4: Does the Name Resolve, and to the Right Machine

The 11001 line is the easiest of the four to fix and the easiest to miss, because the name usually looks right. Resolve it from the server that raised the error, not from your workstation, since the two often use different DNS suffixes:

Resolve-DnsName -Name sqlnode2.corp.invalid -ErrorAction Stop

Resolve-DnsName : sqlnode2.corp.invalid : DNS name does not exist

Three variants of this produce the same 1418 and are worth ruling out in one pass. A short name that resolves on one server and not the other, because only one of them has the right DNS search suffix. A name that resolves to a stale address after a rebuild or a failover. And an address that resolves to an IPv6 address the far end is not listening on, which is the awkward one, because the name looks healthy and the connection still never arrives. Give the fully qualified name in the partner address, and if it still fails, try the IP address once as a test. If the IP works and the name does not, you have a name problem rather than a mirroring problem.

Check 5: The Firewall, and the Parts I Did Not Reproduce

The 10060 line means your packets left and nothing came back, which on a corporate network is a firewall almost every time. The lab reproduced the shape of it by pointing the partner address at an address that blackholes traffic, and the log line is identical to the one a DROP rule produces, but the rule itself was not created, so take this part as documented rather than reproduced.

• The endpoint port needs an inbound rule on both servers, not just on the one you think of as the secondary. Mirroring and Availability Group partners connect in both directions.
• The rule must be on the profile the network adapter is actually in. A rule on the Domain profile does nothing while the adapter has decided it is on a Public network, and that is a common state after a rebuild.
• A refusal is not a drop. If you are seeing 10061 rather than 10060, something answered, so the firewall is probably not your problem and the endpoint is.
• Not reproduced here, and worth knowing anyway: on a domain with Windows authenticated endpoints, 1418 also appears when the two service accounts cannot authenticate each other, for example across a trust or where one instance runs as a local account. That case needs a domain and two member servers to demonstrate honestly, so it is named rather than shown.

The Order Trap: 1475 Comes Before 1418

If SET PARTNER fails and the error log shows no mirroring connection line at all, the statement never reached the network. The usual reason is that the database is not ready to be mirrored yet, and the message you get is a different number entirely:

Msg 1475, Level 16, State 2, Server HPAI01, Line 2
Database "Lab1001b_MirrorDb" might contain bulk logged changes that have not been backed up.
Take a log backup on the principal database or primary database. Then restore this backup
either on the mirror database to enable database mirroring or on every secondary database to
enable you to join it to the availability group.

That one is not a network fault and no amount of firewall work will shift it. The database needs FULL recovery, a full backup and at least one log backup, and the mirror or secondary has to be restored from both with NORECOVERY. Only once that is done does the statement get as far as the endpoint, and only then can a genuine 1418 appear. Worth knowing because a fair number of 1418 reports are actually people who cleared 1475 first, changed something else at the same time, and then attributed the new error to the change.

Common Questions