Fixing “TCP Provider: No connection could be made because the target machine actively refused it.”

The error “TCP Provider: No connection could be made because the target machine actively refused it” (Windows Socket Error 10061) occurs when Excel attempts to establish a network handshake with a SQL Server host, but the host machine sends an active TCP reset (RST packet) back to Excel. This means the destination server machine is reachable on the network, but no database service is actively listening on the requested IP address and port combination.

Quick Answer

To fix “No connection could be made because the target machine actively refused it” (Error 10061), start the SQL Server (MSSQLSERVER) service on the host, enable TCP/IP in SQL Server Configuration Manager, assign port 1433 under IPAll, and open TCP port 1433 in the server’s Windows Firewall.

---

What Causes Error 10061 in Excel Workbooks?

Unlike a generic network timeout where a packet drops into a black hole without a reply, an “actively refused” error is an explicit rejection. The host operating system responded: “I hear you, but no program is listening on this port.”

In Excel reporting workflows, this happens for four distinct reasons:

1. The SQL Server service is stopped, either because of a server reboot, maintenance, or service crash.
2. The TCP/IP protocol is disabled inside SQL Server’s configuration, leaving only Shared Memory active.
3. The instance is configured to use Dynamic Ports (common with SQL Server Express), and the port changed after a service restart while Excel is still looking at port 1433.
4. A firewall rule, proxy, or third-party endpoint security software intercepts the port and issues a rejection reset.

For a complete map of OLE DB and ODBC driver failures, see Troubleshooting SQL Connection Failures: Fixing ODBC and Provider Errors.

---

Step-by-Step Diagnostic and Repair Steps

Step 1: Verify the SQL Server Service State

First, confirm that the database engine is actually running on the target machine.

1. On the database server, press Windows Key + R, type services.msc, and press Enter.
2. Scroll down to locate SQL Server (MSSQLSERVER) for a default instance, or SQL Server ([InstanceName]) for a named instance.
3. Check the Status column:
   • If blank or Stopped, right-click the service and choose Start.
4. Check the Startup Type column:
   • If set to Manual, right-click > Properties, change it to Automatic, and click Apply.

Step 2: Enable TCP/IP and Assign a Static Port

Even if the service is running, SQL Server often defaults to disabling TCP/IP for named installations. You must explicitly verify its network configuration.

1. Open SQL Server Configuration Manager.
2. Expand SQL Server Network Configuration in the left menu.
3. Click Protocols for [YourInstanceName].
4. Right-click TCP/IP and select Enable.
5. Double-click TCP/IP to open the TCP/IP Properties dialog.
6. Click the IP Addresses tab and scroll all the way to the bottom to the IPAll section.
7. Clear any value inside TCP Dynamic Ports.
8. In the TCP Port field, enter: 1433 (or your company’s designated custom SQL port).
9. Click Apply, then OK.
10. Click SQL Server Services in the left pane, right-click your SQL Server instance, and select Restart.

Step 3: Configure Inbound Windows Firewall Rules

If the service is listening on port 1433, the server’s local Windows Firewall may still actively reject incoming requests from other computers on the subnet.

1. On the server machine, open Control Panel > Administrative Tools > Windows Defender Firewall with Advanced Security.
2. Click Inbound Rules in the left pane.
3. Click New Rule… in the right pane.
4. Select Port and click Next.
5. Choose TCP, select Specific local ports, and enter: 1433. Click Next.
6. Select Allow the connection and click Next.
7. Check the boxes for Domain and Private (do not select Public unless required by your network layout). Click Next.
8. Name the rule SQL Server - Inbound Port 1433 and click Finish.

---

Validating Connectivity from the Client Machine

Do not test connectivity by repeatedly refreshing a complex Excel model. Test the transport port directly from the user’s workstation using PowerShell.

Open PowerShell on your desktop and run:

Test-NetConnection -ComputerName YourServerName -Port 1433

• If TcpTestSucceeded : True appears, the port is open and actively accepting connections. Return to Excel and refresh your query.
• If TcpTestSucceeded : False appears:
  • Verify that the server name resolves to the correct IP address using ping YourServerName.
  • Check whether a corporate hardware firewall or VPN tunnel sits between your PC and the database server.
  • If you are connecting across a remote tunnel that drops under load, review Troubleshooting VPN-related connection drops during Power Query refreshes..

---

Deeper Diagnostic Escalation

If port 1433 is open and passes the network test, but Excel still reports connection errors:

• Protocol Fallback Errors: If the driver fails over to Named Pipes after a partial TCP rejection, follow the instructions in Troubleshooting “Named Pipes Provider: Could not open a connection to SQL Server.”.
• Instance Name and Alias Typos: If connecting to a multi-instance server, an incorrect instance name will steer Excel toward the wrong port. See Fixing “The server was not found or was not accessible” (Instance name typos)..
• Encryption Handshake Blocks: Once the TCP socket connects, modern Excel drivers immediately begin negotiating TLS encryption. If the server does not support modern ciphers, the connection will drop during pre-login. Proceed to How to resolve “Encryption mismatch” between Excel and legacy SQL Server versions..