Sql server port — kompletny przewodnik 2026

Standardowy port TCP wykorzystywany przez Microsoft SQL Server to 1433. Ten numer identyfikuje domyślną instancję silnika bazy danych (Database Engine) i odpowiada za komunikację między klientami a serwerem SQL Server na całym świecie — od aplikacji desktopowych .NET, przez usługi IIS i webowe REST API, po rozproszone środowiska z Always On i replikacją transakcyjną. Port 1433 jest przypisany przez IANA organizacji Microsoft i od wersji SQL Server 6.5 pozostaje niezmiennym punktem styku aplikacji z danymi. Jednak w praktyce administratora baz danych sama znajomość domyślnego numeru portu nie wystarcza. Współczesne wdrożenia SQL Server 2022 i Windows Server 2025 wymagają rozumienia różnicy między portami statycznymi i dynamicznymi, mechanizmu działania usługi SQL Server Browser (UDP 1434), konfiguracji zapory, nazwanych instancji, szyfrowania TLS 1.3 oraz zabezpieczeń przed atakami z zewnątrz. W tym przewodniku omawiamy każdy port używany przez ekosystem SQL Server, zasady konfiguracji zapory systemowej i sprzętowej, metody zmiany domyślnego numeru, diagnostykę problemów z połączeniem oraz najlepsze praktyki bezpieczeństwa na 2026 rok. Jeśli zarządzasz serwerem SQL Server i potrzebujesz legalnej licencji — klucze SQL Server 2022 Standard i Enterprise z fakturą VAT 23% znajdziesz w ofercie KluczeSoft.pl.

SQL Server Database Engine — port TCP 1433 i jego rola

Port TCP 1433 jest domyślnym punktem końcowym nasłuchiwania dla domyślnej, nienazwanej instancji SQL Server Database Engine. Gdy instalujesz SQL Server jako instancję domyślną, usługa MSSQLSERVER automatycznie wiąże gniazdo TCP na porcie 1433 dla wszystkich interfejsów sieciowych serwera. Oznacza to, że każdy klient — aplikacja ADO.NET, ODBC, JDBC, PHP PDO, Python pyodbc czy SQL Server Management Studio — który łączy się z serwerem przez sieć, wysyła pierwszy pakiet TCP SYN właśnie na ten port.

Protokół na porcie 1433 działa w architekturze klient-serwer z wykorzystaniem formatu TDS (Tabular Data Stream), autorskiego protokołu Microsoft warstwy aplikacji. TDS hermetyzuje zapytania SQL, wyniki kwerend, komunikaty o błędach, metadane kolumn i sesje transakcyjne w jednostkach zwanych pakietami TDS. Sam transport odbywa się po TCP — nie po UDP (z jednym wyjątkiem, którym zajmiemy się za chwilę). Port 1433 obsługuje zarówno uwierzytelnianie SQL Server (login + hasło), jak i uwierzytelnianie zintegrowane Windows (Kerberos/NTLM), również przez pipe'y nazwane (named pipes), które jednak w środowiskach sieciowych ustępują komunikacji TCP.

W ekosystemie chmurowym Azure SQL Database i Azure SQL Managed Instance również komunikują się przez port 1433 lub 3342 — ten drugi dla prywatnych punktów końcowych Managed Instance. Wszystkie narzędzia klienckie, od Azure Data Studio po sqlcmd, domyślnie kierują ruch na port 1433.

Ważne zastrzeżenie: port 1433 obowiązuje wyłącznie dla domyślnej instancji. Jeśli instalujesz drugą, nazwaną instancję SQL Server na tym samym hoście (np. Serwer\FINANSE), mechanizm DDM (dynamicznego wykrywania portów) przypisuje jej losowy, dynamiczny port TCP — najczęściej z puli wysokiej (49152-65535). W takim przypadku ruch klienta najpierw trafia do usługi SQL Server Browser na porcie UDP 1434, która odpowiada numerem rzeczywistego portu TCP przydzielonego danej instancji.

SQL Server Browser — port UDP 1434

Usługa SQL Server Browser działa jako katalog dla instancji nazwanych. Nasłuchuje na porcie UDP 1434 i odpowiada na zapytania rozgłoszeniowe klientów, zwracając adres IP oraz numer portu TCP, na którym działa żądana instancja. Bez tej usługi aplikacja kliencka musi jawnie określić niestandardowy numer portu w parametrach połączenia (connection string) lub w aliasie konfiguracyjnym klienta.

Mechanizm działania jest prosty, ale krytyczny dla środowisk wieloinstancyjnych:

1. Klient wysyła datagram UDP na adres serwera, port 1434, z zapytaniem o instancję o nazwie np. FINANSE.
2. SQL Server Browser odczytuje rejestr systemu Windows (klucz HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL) i znajduje rzeczywisty port TCP — np. 53421.
3. Browser odpowiada datagramem UDP zawierającym adres IP i numer portu.
4. Klient nawiązuje połączenie TCP na podany port.

Usługa Browser jest domyślnie zatrzymana od SQL Server 2016 ze względów bezpieczeństwa. Atakujący skanujący sieć UDP na porcie 1434 może uzyskać pełną listę działających instancji SQL Server, ich wersji i numerów portów — informacje bezcenne przy przygotowaniu ataku. Dlatego w środowiskach produkcyjnych zaleca się uruchamianie SQL Server Browser wyłącznie na hostach z więcej niż jedną instancją nazwaną. Dla pojedynczej instancji domyślnej Browser jest zbędny, a jego wyłączenie zmniejsza powierzchnię ataku.

SQL Server Integration Services (SSIS), Analysis Services (SSAS) i Reporting Services (SSRS) — porty dodatkowe

Silnik bazy danych nie jest jedyną usługą SQL Server korzystającą z sieci. Kompletna instalacja obejmuje również komponenty analityczne i integracyjne, każdy z własnym portem:

SSAS (Analysis Services) nasłuchuje domyślnie na porcie TCP 2383 dla instancji domyślnej. Instancje nazwane SSAS korzystają z SQL Server Browser (UDP 1434) do dynamicznego przydziału portów, identycznie jak Database Engine.

SSRS (Reporting Services) od wersji SQL Server 2017 nie wymaga już osobnego portu — działa jako usługa HTTP/HTTPS w ramach IIS Express lub jako natywny komponent SharePoint, korzystając ze standardowych portów 80 i 443. Starsze instalacje (SQL Server 2016 i wcześniejsze) domyślnie używają portu 80, konfigurowalnego w pliku RSReportServer.config.

SSIS (Integration Services) opiera się na modelu DCOM, co oznacza komunikację przez port TCP 135 (RPC Endpoint Mapper) i dynamiczny zakres portów RPC (zwykle 49152-65535 na Windows Server 2025). W środowiskach z zaporą sieciową administracja SSIS wymaga albo zawężenia zakresu dynamicznych portów RPC w rejestrze, albo migracji pakietów SSIS do Azure Data Factory, gdzie komunikacja odbywa się przez HTTPS.

Konfiguracja zapory systemowej Windows Server 2025 dla SQL Server

Nieprawidłowa konfiguracja zapory to przyczyna numer jeden nieudanych połączeń z SQL Server po instalacji. Windows Server 2025 domyślnie blokuje cały ruch przychodzący, w tym na porcie 1433. Oto poprawna sekwencja:

Krok 1 — otwarcie portu 1433 w Windows Defender Firewall (PowerShell jako Administrator):

New-NetFirewallRule -DisplayName "SQL Server Database Engine" `
  -Direction Inbound -Protocol TCP -LocalPort 1433 `
  -Action Allow -Profile Domain,Private

Należy unikać otwierania portu 1433 dla profilu Publicznego — to prosta droga do udostępnienia serwera całemu internetowi.

Krok 2 — dla instancji nazwanych: należy dodać regułę na konkretny port TCP (np. 53421) oraz UDP 1434 dla SQL Server Browser. Reguła UDP musi być skonfigurowana również dla profilu, z którego łączą się klienci.

Krok 3 — SSAS (jeśli używany): New-NetFirewallRule -DisplayName "SSAS" -Direction Inbound -Protocol TCP -LocalPort 2383 -Action Allow.

Krok 4 — Service Broker / Always On: porty 4022 i 5022 są wymagane odpowiednio dla Service Broker i punktów końcowych grup dostępności Always On. Reguły należy zawęzić do konkretnych zdalnych adresów IP węzłów klastra.

W środowiskach korporacyjnych z zaporą sprzętową (FortiGate, Palo Alto, pfSense) reguły są analogiczne, ale należy zweryfikować, czy ruch nie jest blokowany między segmentami VLAN. Typowym błędem jest zezwolenie na port 1433 tylko w jednym kierunku — np. z serwera aplikacji do SQL, bez odpowiedzi zwrotnej.

Zmiana domyślnego portu SQL Server — kiedy i jak to zrobić?

Zmiana portu SQL Server z 1433 na niestandardowy to jedna z najprostszych i zarazem najskuteczniejszych technik ograniczania ataków automatycznych (botów skanujących internet w poszukiwaniu otwartego portu 1433). SQL Server Management Studio oraz SQL Server Configuration Manager umożliwiają modyfikację konfiguracji w 2 minuty:

1. Otwórz SQL Server Configuration Manager.
2. W gałęzi SQL Server Network Configuration wybierz Protocols for <nazwa_instancji>.
3. Kliknij prawym przyciskiem na TCP/IP → Properties.
4. W zakładce IP Addresses znajdź wpis IPAll i w polu TCP Port wpisz nowy numer (np. 18543). Pole TCP Dynamic Ports musi być puste — inaczej SQL Server zignoruje port statyczny.
5. Zrestartuj usługę SQL Server.

Po zmianie każdy connection string musi jawnie wskazywać numer portu: Server=sql01.twojafirma.pl,18543;Database=HR;....

Istotne ograniczenie: porty poniżej 1024 wymagają uprawnień administratora i są zarezerwowane dla usług systemowych. Porty z zakresu 1024-49151 to zarejestrowane porty użytkownika — należy wybierać spośród nich, unikając znanych usług (np. 3306 dla MySQL, 5432 dla PostgreSQL, 3389 dla RDP, 8080 dla HTTP). Zakres 49152-65535 to porty efemeryczne wykorzystywane przez system do połączeń wychodzących — teoretycznie również dostępne, ale w praktyce lepiej unikać konfliktów.

W Azure SQL Database zmiana portu nie jest dostępna — usługa zawsze komunikuje się przez 1433 dla publicznych punktów końcowych i 3342 dla prywatnych punktów Managed Instance. W zamian Microsoft zapewnia wbudowaną zaporę serwerową (Server Firewall Rules) z whitelistą adresów IP.

Diagnostyka połączenia — narzędzia i metody rozwiązywania problemów

Gdy aplikacja nie może połączyć się z SQL Server, kluczowe jest metodyczne wykluczanie przyczyn. Oto sprawdzony workflow diagnostyczny na 2026 rok:

1. Test łączności TCP (nie SQL!)

Zanim zaczniesz analizować connection string, potwierdź, że port jest w ogóle dostępny sieciowo:

Test-NetConnection -ComputerName sql01 -Port 1433

Sukces (TcpTestSucceeded : True) oznacza, że trasa sieciowa jest drożna i port nasłuchuje. Błąd wskazuje na zaporę, brak usługi na porcie lub izolację sieciową (VLAN, VNet, NSG w Azure).

2. Test SQL z sqlcmd

sqlcmd -S sql01,1433 -U sa -Q "SELECT @@VERSION"

Jeśli sqlcmd łączy się poprawnie, ale aplikacja nie — problemem jest connection string, sterownik (np. nieaktualny ODBC Driver 18), biblioteka TLS/SSL lub nieprawidłowe uwierzytelnianie.

3. Weryfikacja nasłuchu — netstat

netstat -an | findstr "1433"

Wynik LISTENING potwierdza, że SQL Server nasłuchuje na porcie. Wynik TIME_WAIT lub brak wpisu oznacza, że usługa nie działa, port jest skonfigurowany błędnie albo SQL Server nasłuchuje wyłącznie na 127.0.0.1 (shared memory/local only).

4. Logi błędów SQL Server

Plik ERRORLOG w katalogu C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Log\ zawiera wpisy o porcie nasłuchu podczas startu:

Server is listening on [ 'any' <ipv4> 1433]

Brak takiego wpisu oznacza, że protokół TCP/IP nie jest włączony w SQL Server Configuration Manager, co zdarza się po instalacji Express Edition, gdzie domyślnie włączone jest tylko Shared Memory.

5. SQL Server Browser — czy odpowiada?

Dla instancji nazwanych:

$client = New-Object System.Net.Sockets.UdpClient
$client.Connect("sql01", 1434)
$query = [byte]0x02  # CLNT_BCAST_EX
$client.Send($query, $query.Length)
$response = $client.Receive([ref]$null)

Nieprawidłowa odpowiedź (lub jej brak) oznacza zatrzymaną usługę Browser lub blokadę UDP 1434 na zaporze.

Szyfrowanie połączeń — TLS 1.3, certyfikaty i port 1433

Od SQL Server 2022 komunikacja klient-serwer może być szyfrowana z wykorzystaniem TLS 1.3 — najnowszej wersji protokołu transportowej warstwy bezpieczeństwa, eliminującej podatności TLS 1.2 (np. BEAST, Lucky13) i redukującej narzut negocjacji sesji o 1 RTT. Szyfrowanie nie zmienia numeru portu (1433 pozostaje 1433), ale wymaga spełnienia warunków:

• SQL Server 2022 z aktualizacją zbiorczą CU5 lub nowszą na Windows Server 2025 (lub Windows 11 24H2/25H2 dla wersji Developer).
• Certyfikat SSL/TLS z kluczem prywatnym w magazynie certyfikatów komputera lokalnego, w gałęzi Personal.
• Wymuszenie szyfrowania w SQL Server Configuration Manager (Properties → Flags → Force Encryption = Yes).
• W connection string: Encrypt=True;TrustServerCertificate=False;.

Port 1433 z TLS 1.3 zachowuje kompatybilność wsteczną — klienci nieobsługujący TLS 1.3 negocjują TLS 1.2, o ile SQL Server ma go włączonego. Wyłączenie TLS 1.2 i pozostawienie wyłącznie TLS 1.3 jest najlepszą praktyką na 2026 rok, ale wymaga upewnienia się, że wszystkie sterowniki klienckie (ODBC Driver 18, JDBC 12.x, Microsoft.Data.SqlClient 5.x) obsługują nowy protokół.

W Azure SQL Database szyfrowanie jest wymuszone zawsze — port 1433 zawsze używa TLS, a próba połączenia nieszyfrowanego kończy się błędem.

Bezpieczeństwo portu SQL Server — lista kontrolna na 2026 rok

Ekspozycja portu 1433 do internetu to jeden z najczęstszych wektorów ataków na infrastrukturę bazodanową. Boty skanujące przestrzeń IPv4 w poszukiwaniu otwartego portu 1433 próbują domyślnych haseł konta sa, a po uzyskaniu dostępu instalują ransomware szyfrujące pliki MDF i LDF. Poniższa lista to absolutne minimum dla każdego administratora:

1. Nigdy nie wystawiaj portu 1433 bezpośrednio do internetu. SQL Server powinien być dostępny wyłącznie z wewnętrznej sieci firmowej lub przez VPN (WireGuard, OpenVPN, Azure VPN Gateway).
2. Nie używaj konta sa do połączeń aplikacyjnych. Każda aplikacja powinna mieć własne konto z minimalnymi uprawnieniami (EXECUTE na procedurach, SELECT na widokach, bez CREATE/ALTER/DROP).
3. Włącz logowanie nieudanych prób logowania w SQL Server Audit i monitoruj Security Event Log Windows (Event ID 18456 — nieudane logowanie SQL).
4. Zmień domyślny port 1433 na niestandardowy w środowiskach, gdzie to możliwe (z wyjątkiem Azure SQL DB).
5. Ogranicz źródłowe adresy IP w regule zapory — nie używaj Any (0.0.0.0/0), wskaż konkretne zakresy sieci firmowej.
6. Włącz TLS 1.3 i wymuś szyfrowanie połączeń — nawet w sieci wewnętrznej, aby zapobiec sniffingowi TDS przez skompromitowane urządzenie.
7. Audytuj porty regularnie przy użyciu nmap -p 1433,1434,2383,4022,5022 <zakres IP> w ramach firmowych pentestów.
8. Wyłącz SQL Server Browser, jeśli nie masz nazwanych instancji — usuwasz cały wektor UDP 1434.
9. Wyłącz protokół Named Pipes i Shared Memory na serwerach dostępnych sieciowo — pozostaw wyłącznie TCP/IP. Redukujesz powierzchnię ataku na mechanizmy IPC.
10. W ekosystemie Microsoft Entra ID (dawniej Azure AD): skonfiguruj dostęp warunkowy (Conditional Access) wymagający MFA dla dostępu do Azure SQL DB przez port 1433.

W przypadku firm, które muszą udostępnić SQL Server partnerom zewnętrznym, rozwiązaniem jest Azure SQL Managed Instance z Private Endpoint i Azure Private Link — cała komunikacja odbywa się wewnątrz sieci wirtualnej Azure, bez publicznych adresów IP.

SQL Server w kontenerach i Kubernetes — porty w Docker i AKS

Rosnąca popularność konteneryzacji nie omija SQL Server. SQL Server 2022 działa natywnie w kontenerach Linux (Ubuntu 22.04 LTS) i Windows Server Core, a port 1433 jest mapowany przez flagę -p w Docker lub przez port w Kubernetes Service YAML:

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=TwojeHasło123!" \
  -p 1433:1433 --name sql2022 -d mcr.microsoft.com/mssql/server:2022-latest

W środowiskach orkiestracji Kubernetes (AKS, EKS, GKE) definicja serwisu wygląda następująco:

apiVersion: v1
kind: Service
spec:
  ports:
    - name: sql
      port: 1433
      targetPort: 1433
      protocol: TCP
  type: ClusterIP

W przypadku wielu instancji SQL Server w tym samym klastrze, każda musi używać innego targetPort kontenera (i np. różnych portów węzła w type: NodePort) — kolizje portów na jednym hoście Kubernetes są niedopuszczalne. Alternatywą jest użycie type: LoadBalancer z Azure Load Balancer, który przekierowuje ruch na port 1433 wewnętrznego klastra.

Istotna różnica wobec SQL Server na Windows: w kontenerze Linux SQL Server Browser nie jest dostępny. Każda instancja kontenerowa ma dokładnie jeden port TCP skonfigurowany przez zmienną środowiskową MSSQL_TCP_PORT. Dla wielu instancji nazwanych na jednym hoście konteneryzacja wręcz wymusza separację — każda instancja to osobny kontener z własnym portem.

Częste pytania

Jaki jest domyślny port SQL Server?

Domyślny port SQL Server Database Engine to TCP 1433. Dotyczy domyślnej, nienazwanej instancji. Instancje nazwane (np. Serwer\HR) korzystają z dynamicznych portów TCP przydzielanych przez system, a ich rzeczywisty numer portu można odczytać przez zapytanie do usługi SQL Server Browser na porcie UDP 1434.

Czy port 1433 używa TCP czy UDP?

Port 1433 używa TCP. Cała komunikacja TDS (Tabular Data Stream) między klientem a SQL Server odbywa się po TCP. UDP na porcie 1434 jest używany wyłącznie przez usługę SQL Server Browser do dynamicznego rozwiązywania nazwanych instancji.

Jak sprawdzić, na którym porcie działa mój SQL Server?

Wykonaj w PowerShell: netstat -an | findstr "LISTENING" | findstr ":1433" — lub sprawdź konfigurację TCP/IP w SQL Server Configuration Manager. Alternatywnie, w SQL Server Management Studio kliknij prawym przyciskiem na instancję → Properties → General → Connection. Możesz też odczytać wpis w pliku ERRORLOG w katalogu Log SQL Server.

Jak zmienić port SQL Server z 1433 na inny?

Otwórz SQL Server Configuration Manager, wejdź w SQL Server Network Configuration → Protocols for <instancja> → TCP/IP → Properties → zakładka IP Addresses → IPAll → pole TCP Port — wpisz nowy numer portu, wyczyść pole TCP Dynamic Ports. Zrestartuj usługę SQL Server. Pamiętaj o aktualizacji connection stringów: Server=sql01,nowyport;.

Czy da się uruchomić SQL Server na porcie innym niż 1433 w Azure?

W Azure SQL Database (PaaS) nie ma możliwości zmiany portu — komunikacja zawsze odbywa się przez port 1433 (publiczny endpoint) lub 3342 (private endpoint Managed Instance). W Azure VM z własnym SQL Server możesz zmienić port identycznie jak on-premises.

Dlaczego klient nie może połączyć się z SQL Server przez sieć?

Najczęstsze przyczyny to: (1) zapora blokująca port 1433, (2) protokół TCP/IP wyłączony w SQL Server Configuration Manager, (3) SQL Server nasłuchuje tylko na localhost (127.0.0.1), (4) usługa SQL Server Browser zatrzymana dla instancji nazwanej, (5) nieprawidłowy connection string (brak numeru portu po przecinku), (6) błąd TLS — klient nie obsługuje wymaganej wersji szyfrowania. Rozpocznij od Test-NetConnection -ComputerName sql01 -Port 1433.

Czy port 1433 powinien być otwarty w zaporze dla całego internetu?

Absolutnie nie. Otwieranie portu 1433 do internetu to poważny błąd bezpieczeństwa. SQL Server powinien być dostępny wyłącznie w sieci wewnętrznej firmy lub przez VPN. Boty stale skanują internet w poszukiwaniu otwartego portu 1433 i automatycznie próbują ataków słownikowych na konto sa.

Jakie inne porty są wymagane dla ekosystemu SQL Server?

Oprócz TCP 1433 (Database Engine) i UDP 1434 (Browser), potrzebujesz: TCP 2383 dla SSAS, TCP 80/443 dla SSRS, TCP 135 i dynamiczny zakres RPC dla SSIS, TCP 5022 dla Always On Availability Groups, TCP 4022 dla Service Broker. Szczegółowa tabela znajduje się w sekcji o portach dodatkowych.

Czy TLS 1.3 działa z SQL Server?

Tak, SQL Server 2022 z aktualizacją CU5 lub nowszą na Windows Server 2025 i Windows 11 24H2/25H2 obsługuje TLS 1.3. Szyfrowanie nie zmienia numeru portu — 1433 pozostaje 1433. Wymagana jest konfiguracja certyfikatu i wymuszenie szyfrowania w SQL Server Configuration Manager.

Czy mogę mieć dwa SQL Servery na tym samym porcie?

Nie — na jednym hoście dwa procesy nie mogą nasłuchiwać na tym samym porcie TCP. Jeśli instalujesz drugą, nazwaną instancję, SQL Server automatycznie przydziela jej inny, dynamiczny port TCP. Klient dowiaduje się o nim przez zapytanie do SQL Server Browser (UDP 1434). Rozwiązaniem alternatywnym jest konteneryzacja — każda instancja w osobnym kontenerze Docker z własnym portem mapowanym na różne porty hosta.

Jak wyłączyć zbędny port SQL Server Browser w firmie z jedną instancją?

Zatrzymaj i wyłącz usługę SQL Server Browser w services.msc lub PowerShell: Stop-Service "SQLBrowser" -Force; Set-Service "SQLBrowser" -StartupType Disabled. Upewnij się, że wszystkie connection stringi odwołują się do instancji domyślnej lub jawnie określają port TCP. Dla pojedynczej instancji domyślnej Browser jest całkowicie zbędny.

Zarządzasz wdrożeniem SQL Server 2022 i potrzebujesz legalnych licencji na Windows Server 2025 oraz SQL Server Standard lub Enterprise? W KluczeSoft.pl otrzymujesz oryginalne klucze Microsoft z fakturą VAT 23%, natychmiastową dostawą e-mail i polskojęzycznym wsparciem — bez ryzyka blokady licencji z nieautoryzowanego źródła. Sprawdź ofertę kluczy SQL Server →

Sprawdź też

• Sql server management studio — kompletny przewodnik 2026
• Ms SQL Server Express — kompletny przewodnik 2026
• SQL Server — kompletny przewodnik 2026
• Sql Server Express — kompletny przewodnik 2026

Potrzebujesz licencji? Microsoft SQL Server — sprawdź ofertę KluczeSoft.pl — legalne klucze, faktura VAT, dostawa e-mail.