Change Sql Server Port: Complete Security Step-by-step Guide

Leaving Microsoft SQL Server on its default port of 1433 invites automated scanners, credential stuffing attacks, and brute-force break-ins. Every database exposed directly to the internet on port 1433 logs thousands of connection attempts daily from automated botnets. Shifting your database instance to a non-standard port isn't a silver bullet against targeted threats, but it instantly eliminates the background noise of automated scripts scanning public IP ranges.

You'll need administrative access to the Windows host running SQL Server, access to SQL Server Configuration Manager, and permissions to configure Windows Defender Firewall rules. Let's walk through how to change your port safely without cutting off your applications.

Why Change the Default Port

By default, SQL Server listens on TCP port 1433 for standard database engine instances. Because this port is universally known, attackers write scripts to probe every IP address they find for open 1433 ports.

Moving away from port 1433 implements security through obscurity, which sounds weak on paper, but functions as an effective filter against untargeted, automated malware sweeps. When you combine a custom port with encrypted connections, strong authentication policies, and restricted firewall rules, you significantly raise the cost of entry for unauthorized parties.

For named instances, SQL Server typically relies on the SQL Server Browser service running on UDP port 1434 to dynamically assign ports to incoming requests. However, keeping the browser service active can expose your server version and instance names. Assigning static ports to named instances lets you disable the browser service entirely, reducing your surface area.

Step 1: Configuring a Static Port in SQL Server Configuration Manager

Before touching your applications, configure SQL Server to listen on a specific, chosen port number. Pick a port outside the well-known range (0-1023) and registered range (1024-49151), such as a high-numbered port between 50000 and 65535.

1. Open SQL Server Configuration Manager on your database host via the Start menu or by running SQLServerManagerXX.msc (where XX matches your version number).
2. Expand SQL Server Network Configuration in the left-hand console tree and select Protocols for [YourInstanceName].
3. Right-click TCP/IP in the pane on the right and click Properties.
4. Switch to the IP Addresses tab in the dialog window.
5. Scroll down to the bottom to find the IPAll section.
6. Clear any value inside the TCP Dynamic Ports field. If a zero is present, delete it so the box is completely empty. This step is critical; if dynamic ports are left active, SQL Server will ignore your static port assignment on reboot.
7. Enter your new custom port number (for example, 51433) into the TCP Port field under IPAll. Alternatively, you can configure individual IP addresses in the list above if you want the instance listening on different ports per network interface.
8. Click Apply, then click OK. A warning prompt will remind you that services must be restarted for changes to take effect.

Step 2: Restarting the SQL Server Service

Your configuration changes won't take effect until the database engine process restarts.

1. Select SQL Server Services at the top of the left-hand navigation tree in SQL Server Configuration Manager.
2. Locate your specific instance—such as SQL Server (MSSQLSERVER) for default instances or SQL Server (INSTANCENAME) for named instances.
3. Right-click the service and select Restart.
4. Watch the progress bar until the status indicator returns to Running.

You can verify that SQL Server is listening on your new port by opening PowerShell as an administrator and running:

Get-NetTCPConnection -LocalPort 51433

If the command returns an active listening state tied to sqlservr.exe, your configuration is loaded correctly.

Step 3: Updating Windows Firewall Rules

Your operating system firewall blocks external traffic by default. Because you changed the listening port, incoming connections targeting your old port will fail, and incoming traffic on your new port will be blocked unless you explicitly permit it.

1. Open Windows Defender Firewall with Advanced Security from administrative tools.
2. Click Inbound Rules in the left pane, then click New Rule... in the right actions pane.
3. Choose Port as the rule type and click Next.
4. Select TCP and specify your custom port number (e.g., 51433) in the Specific local ports field. Click Next.
5. Select Allow the connection and click Next.
6. Check the network location profiles (Domain, Private, Public) that apply to your environment. For production servers exposed to specific subnets, restrict this rule strictly to trusted IP addresses using scope settings later.
7. Give the rule a clear name, such as SQL Server Custom TCP Port, and click Finish.

If you had an old firewall rule allowing TCP 1433, disable or delete it to prevent lingering exposure paths.

Step 4: Updating Connection Strings and Client Applications

With the database listening on a new port, every application connecting to this instance must update its connection string. When a database moves off port 1433, standard connection strings fail because clients default to looking at port 1433.

For standard ADO.NET or Entity Framework connections, format your server address by appending a comma and the new port number:

Server=myServerAddress,51433;Database=myDataBase;User Id=myUsername;Password=myPassword;

For SQL Server Management Studio (SSMS) connections, enter the server name followed by a comma and the port in the server name prompt:

sqlserver01.internal.domain,51433

Never use a colon (:) for SQL Server port designation in standard connection strings; SQL Server expects a comma (server,port), whereas other database engines like MySQL or PostgreSQL use colons.

Common Mistakes to Avoid

• Leaving TCP Dynamic Ports populated: If you put a port in the TCP Port field under IPAll but leave a 0 in TCP Dynamic Ports, SQL Server ignores your static port every time the service restarts. Always clear the dynamic port box.
• Forgetting client updates: Changing the server port without updating upstream applications causes immediate outages for web apps, reporting tools, and background services. Plan your cutover window carefully.
• Neglecting secondary network interfaces: If your server has multiple network adapters bound to different IPs, make sure you configure the correct IP section in the TCP/IP properties.

Frequently Asked Questions

Can I run multiple SQL Server instances on different ports?

Yes. Each instance runs as an independent service and binds to its own dedicated TCP port. Assigning unique static ports to each named instance lets you run them securely without relying on the SQL Server Browser service.

Do I need to keep UDP port 1434 open?

If you configured all your client applications and connection strings to use explicit static ports, you can disable the SQL Server Browser service and block UDP port 1434 at the firewall. This hardens your server against enumeration attacks.

What should I do if client applications cannot connect after the change?

First, verify that the SQL Server service restarted successfully and is listening on the new port using PowerShell. Second, check your Windows Firewall rules to ensure inbound TCP traffic on the new port is allowed. Finally, double-check that your client connection strings use a comma separator instead of a colon before the port number.

Is port obfuscation enough to protect my database?

No. Changing your port number deters automated scripts and casual scanners, but determined attackers using comprehensive port scans will discover the open port. Always pair port changes with strong password policies, encrypted connections via TLS, multi-factor authentication where possible, and strict IP whitelisting at the firewall level. You can read more about securing database endpoints in official documentation from Microsoft Learn.