Sql Server Ports — Kompletny Przewodnik 2026

Nawet najlepiej skonfigurowany SQL Server nie odpowie na zapytanie, jeśli port pozostanie zamknięty na firewallu, a klient nie będzie wiedział, gdzie pukać. W firmowych wdrożeniach Microsoft SQL Server warstwa sieciowa stanowi pierwszą barierę, z którą mierzy się każdy administrator baz danych, integrator ERP i zespół DevOps. Błędne ustawienie portów to także najczęstsza przyczyna nieudanych połączeń JDBC, ODBC oraz problemów z replikacją. W 2026 roku, gdy rośnie popularność konteneryzacji SQL Server na Kubernetes oraz hybrydowych topologii łączących instancje on-premises z Azure SQL Managed Instance, pytanie o to, które porty muszą być otwarte, powraca w każdym audycie bezpieczeństwa. Ten przewodnik zbiera reguły dotyczące domyślnych i dynamicznych portów, protokołów, konfiguracji zapory systemu Windows i Linux, wyjątków dla wysokiej dostępności oraz praktyk bezpieczeństwa. Wszystkie informacje są aktualne dla SQL Server 2022 (wsparcie mainstreamowe trwa) oraz świeżo wydanego SQL Server 2025 — dwóch głównych wydań eksploatowanych produkcyjnie w 2026 roku.

Jeśli planujesz wdrożenie nowego serwera lub migrację, potrzebujesz nie tylko wiedzy o portach, lecz także legalnej licencji — sprawdź dostępne pakiety SQL Server w sklepie KluczeSoft.pl.

Dlaczego znajomość portów SQL Server ma znaczenie w 2026 roku

Jeszcze dekadę temu administrator otwierał port 1433 na zaporze korporacyjnej i uznawał sprawę za zamkniętą. Dziś topologie są wielowarstwowe: instancje nazwane korzystają z dynamicznych portów przydzielanych przez usługę SQL Server Browser, kontenery Docker otrzymują własny stos sieciowy, a grupy dostępności Always On wymagają osobnych endpointów. Do tego dochodzą wymogi compliance — normy ISO 27001:2022, Dyrektywa NIS 2 obowiązująca w Unii Europejskiej oraz amerykański CMMC 2.0 nakazują dokumentowanie każdej reguły firewallowej wraz z uzasadnieniem biznesowym. Nie można po prostu „otworzyć wszystkich portów”.

Równolegle zmienił się profil atakujących. Ransomware często wykorzystuje niezabezpieczone instancje SQL Server dostępne z Internetu — domyślny port 1433 skanują boty w ciągu kilku minut od przypisania publicznego adresu IP. W 2026 roku Microsoft domyślnie blokuje port 1433 na zaporze Windows w nowo instalowanych instancjach, wymuszając świadome odblokowanie. Znajomość dokładnego zestawu portów, wraz z ich przeznaczeniem, to warunek konieczny zarówno szybkiego wdrożenia, jak i zdania audytu bezpieczeństwa.

Domyślne porty instancji domyślnej i nazwanej

SQL Server rozróżnia instancje domyślne oraz nazwane i przypisuje im porty według odmiennych reguł.

Instancja domyślna (MSSQLSERVER) nasłuchuje na porcie TCP 1433. Jest to wartość zapisana w rejestrze lub pliku konfiguracyjnym i może zostać zmieniona ręcznie. Klient łączący się z instancją domyślną nie musi podawać numeru portu — sterownik zakłada 1433, chyba że parametry połączenia wskazują inaczej.

Instancja nazwana w SQL Server 2022 i 2025 domyślnie korzysta z portu dynamicznego, przydzielanego przez system operacyjny z puli efemerycznej. Oznacza to, że numer może zmienić się po restarcie usługi. Aby klient mógł poznać aktualny port, na serwerze musi działać usługa SQL Server Browser (port UDP 1434). To właśnie ona odpowiada na żądanie klienta, zwracając numer portu TCP dla wskazanej instancji nazwanej.

Praktyka produkcyjna od lat odchodzi od portów dynamicznych na rzecz przypisania stałego portu TCP dla każdej instancji nazwanej. Eliminuje to zależność od usługi Browser (którą wielu administratorów wyłącza z powodów bezpieczeństwa) i upraszcza konfigurację zapór sieciowych. Aby przypisać stały port, należy otworzyć SQL Server Configuration Manager, przejść do konfiguracji sieciowej instancji, wybrać protokół TCP/IP, w zakładce „Adresy IP” usunąć zero z pola „Porty dynamiczne TCP” i wpisać wybrany numer — na przykład 1435, 1436 — w polu „Port TCP”.

W systemie Linux (SQL Server 2017+, w tym 2022 i 2025) konfigurację przechowuje plik /var/opt/mssql/mssql.conf, a sieć TCP/IP włącza się globalnym przełącznikiem przy pomocy narzędzia mssql-conf.

Usługa SQL Server Browser i port UDP 1434

SQL Server Browser to lekka usługa systemu Windows, która w języku formalnym pełni funkcję resolvera nazw instancji na numery portów. Nasłuchuje wyłącznie na UDP 1434 i realizuje dwa zadania: zwraca listę dostępnych instancji wraz z numerami portów oraz przyjmuje rozgłoszeniowe zapytania klientów, którzy nie znają szczegółów połączenia.

Współczesne wytyczne Microsoftu zalecają wyłączenie SQL Server Browser w środowiskach, gdzie aplikacje łączą się przez zdefiniowane na sztywno connection stringi. Powodów jest kilka. Po pierwsze, ruch UDP łatwo sfałszować — atakujący może wysyłać zapytania rozgłoszeniowe i mapować infrastrukturę. Po drugie, Browser działa w kontekście konta usługi i jego ewentualna podatność otwiera drogę do eskalacji uprawnień. Po trzecie, w kontenerach oraz klastrach Kubernetes usługa Browser nie jest dostępna i klient i tak musi znać port.

Jeśli jednak w organizacji korzysta się z wielu instancji nazwanych z portami dynamicznymi (na przykład w środowiskach deweloperskich), port UDP 1434 musi być otwarty między podsiecią klientów a serwerem SQL. Uwaga: nie należy przekierowywać tego portu na publiczny Internet.

Porty wymagane dla wysokiej dostępności: Always On i klastry failover

Grupy dostępności Always On (Availability Groups) wprowadzają dodatkowy zestaw portów TCP, bez których synchronizacja replik nie działa.

Endpoint Always On — osobny port TCP wybierany przez administratora podczas tworzenia endpointu. Najczęściej stosuje się numer 5022 (wartość konwencyjna, nie wymuszona przez Microsoft). Endpoint ten odpowiada za komunikację między replikami: wysyłanie bloków dziennika transakcji, potwierdzenia commitów oraz ruch związany z odczytywaniem danych z replik pomocniczych. Port musi być otwarty dwukierunkowo między wszystkimi węzłami grupy dostępności — jeśli replika znajduje się w innej lokalizacji (rozproszona grupa dostępności, distributed AG), reguły firewallowe należy skonfigurować również na poziomie sieci rozległej lub tunelu VPN.

Port nasłuchiwania (listener) — wirtualny adres IP i nazwa sieciowa, pod którą aplikacje łączą się z grupą dostępności. Listener działa na standardowym porcie TCP wybranym przy jego tworzeniu — domyślnie jest to 1433, ale nic nie stoi na przeszkodzie, aby użyć innego numeru. Port ten musi być dostępny z podsieci klientów do wszystkich węzłów grupy dostępności, ponieważ po failoverze ruch trafia do innego fizycznego hosta.

Klaster Windows Server Failover (WSFC) — mechanizm podstawowy dla Always On (w SQL Server na Linuxie zastąpiony przez Pacemaker). Komunikacja klastrowa wykorzystuje zestaw portów TCP: 3343 (domyślnie dla klastra failover), 445 (SMB do udostępniania plików quorum), 135 (RPC), 49152–65535 (zakres dynamiczny RPC dla wysokich portów) oraz 389 (LDAP). W wielu środowiskach produkcyjnych zamiast otwierać pełen zakres wysokich portów, administratorzy ograniczają pulę RPC przez rejestr Windows, zmniejszając ją do na przykład 5000–5099.

Porty dla dodatkowych usług SQL Server

Poza silnikiem bazodanowym, w ekosystemie SQL Server działa szereg usług pomocniczych. Każda z nich może potrzebować własnego portu lub przynajmniej dostępu do silnika.

SQL Server Analysis Services (SSAS) — domyślny port TCP 2382 dla instancji domyślnej. Instancje nazwane SSAS korzystają z Browsera i portu dynamicznego, chyba że administrator przypisze stały port. SSAS używa także TCP 2383 (protokół SSAS w starszych wersjach, zachowany dla wstecznej kompatybilności). W środowiskach Power BI i Excel, gdzie zapytania DAX lub MDX trafiają bezpośrednio do SSAS, zamknięcie tego portu skutkuje błędami typu „nie można połączyć się ze źródłem danych”.

SQL Server Integration Services (SSIS) — sam serwis SSIS nie otwiera własnego portu (korzysta z portu SQL Server do zapisu/odczytu katalogu SSISDB), ale składniki Scale Out (wprowadzone w SQL Server 2017 i rozwijane do 2025 roku) potrzebują portów TCP 8391 (master) i 8392 (worker) do komunikacji wewnętrznej.

SQL Server Reporting Services (SSRS) — serwer raportów działa jako aplikacja webowa. Domyślnie wykorzystuje port TCP 80 (HTTP) lub 443 (HTTPS), zależnie od konfiguracji. W praktyce organizacje najczęściej wdrażają SSRS na dedykowanym serwerze webowym — porty 80/443 są wtedy oczywiste, ale w razie kolizji można skonfigurować alternatywne. Do połączenia z bazą ReportServer wykorzystuje standardowy port silnika SQL.

Usługa SQL Server Agent — nie ma własnego portu sieciowego. Łączy się z lokalną instancją SQL Server przez shared memory (lokalnie) lub TCP/IP, jeśli Agent działa na zdalnym hoście (rzadka konfiguracja).

PolyBase (SQL Server 2019+) — usługa pośrednicząca w dostępie do zewnętrznych źródeł danych (Hadoop, Azure Blob Storage, S3). Wymaga portów TCP w zakresie 16450–16460 dla komunikacji między węzłami PolyBase. Zakres ten musi być otwarty lokalnie między usługami PolyBase Engine a PolyBase Data Movement.

Konfiguracja firewalla Windows i Linux krok po kroku

Poprawna konfiguracja zapory sieciowej zaczyna się od zidentyfikowania, które komponenty komunikują się przez które protokoły, i zdefiniowania reguł w modelu najmniejszych uprawnień.

Windows Firewall z zabezpieczeniami zaawansowanymi

Na Windows Server 2022 i 2025 (najczęściej spotykanych platformach dla SQL Server w 2026 roku) rekomenduje się tworzenie reguł przychodzących ograniczonych do konkretnych adresów IP lub podsieci źródłowych. Poniższy przykład demonstruje otwarcie portu 1433 wyłącznie dla serwera aplikacji o adresie 10.1.2.100:

New-NetFirewallRule -DisplayName "SQL Server - port 1433 z AppServer" `
  -Direction Inbound -Protocol TCP -LocalPort 1433 `
  -RemoteAddress 10.1.2.100 -Action Allow

Analogiczne reguły trzeba utworzyć dla portu endpointu Always On (np. 5022), dla SSAS (2382), a także dla SQL Server Browser (UDP 1434), jeśli pozostaje włączony. W przypadku klastra failover konieczne jest również otwarcie reguł na ruch między węzłami.

Ważna uwaga praktyczna: zapora Windows domyślnie blokuje ruch wychodzący. SQL Server zazwyczaj nie inicjuje połączeń wychodzących (wyjątki to linked servers, zapytania rozproszone, Database Mail — SMTP na porcie 25 lub 587), więc większość reguł dotyczy kierunku przychodzącego.

Linux (firewalld / iptables / nftables)

Na systemach Red Hat Enterprise Linux 8/9, Ubuntu Server 24.04 LTS (wspieranych dla SQL Server 2022/2025) konfiguracja zależy od wybranego backendu zapory. Najprostszym i zalecanym narzędziem jest firewalld, dostępny domyślnie w RHEL, CentOS i Fedorze.

# Dodanie portu 1433 do strefy publicznej
firewall-cmd --permanent --zone=public --add-port=1433/tcp

# Otwarcie portu dla endpointu Always On
firewall-cmd --permanent --zone=public --add-port=5022/tcp

# Przeładowanie konfiguracji
firewall-cmd --reload

Na Ubuntu (gdzie domyślnie działa ufw) składnia wygląda następująco:

ufw allow from 10.1.2.0/24 to any port 1433 proto tcp
ufw allow from 10.1.2.0/24 to any port 5022 proto tcp
ufw enable

W obu przypadkach architektura docelowa powinna odzwierciedlać model zero-trust: reguły definiuje się nie tylko per port, ale również per źródłowy adres IP lub podsieć.

SQL Server w kontenerach Docker

Kontener SQL Server uruchamiany z obrazu mcr.microsoft.com/mssql/server:2022-latest domyślnie mapuje port wewnątrz kontenera (1433) na port hosta. Użytkownik decyduje, który port hosta zostanie użyty:

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=..." \
  -p 1433:1433 -d mcr.microsoft.com/mssql/server:2022-latest

W takim scenariuszu reguły firewalla definiuje się dla portu hosta (1433), a warstwa overlay sieci Docker automatycznie przekazuje ruch do kontenera. Gdy na jednym hoście działa wiele kontenerów SQL Server, należy użyć różnych portów hosta i odpowiednio skonfigurować connection stringi.

Połączenia szyfrowane i port 1433: czy TLS zmienia reguły?

Od SQL Server 2022 szyfrowanie TLS jest egzekwowane domyślnie dla nowo tworzonych połączeń — zmiana wynikająca z aktualizacji polityki bezpieczeństwa Microsoft. Nie oznacza to jednak, że zmienia się numer portu. Połączenie szyfrowane i nieszyfrowane odbywa się przez ten sam port — zazwyczaj 1433 — a negocjacja TLS następuje na poziomie warstwy transportowej bezpośrednio po nawiązaniu sesji TCP.

Wyjątkiem jest scenariusz z dedykowanym portem administracyjnym (DAC, Dedicated Administrator Connection), który domyślnie nasłuchuje na TCP 1434. DAC służy wyłącznie do awaryjnego dostępu, gdy silnik nie odpowiada na zwykłe połączenia, i zezwala tylko na jedno połączenie administratorskie.

W 2026 roku większość audytorów oczekuje potwierdzenia, że cały ruch do SQL Server odbywa się z włączonym szyfrowaniem (parametr Encrypt=Yes w connection stringu lub Force Encryption włączone po stronie serwera). Odrębny port dla TLS nie istnieje — cała konfiguracja sprowadza się do certyfikatu zainstalowanego w magazynie certyfikatów lokalnego komputera (Windows) lub pliku PEM wskazanego w mssql.conf (Linux).

Błędy połączeń i diagnostyka portów

Nawet w starannie skonfigurowanym środowisku problemy z portami stanowią pierwszy trop przy diagnostyce błędów połączeń. Trzy najczęstsze komunikaty w 2026 roku to:

Komunikat błędu	Przyczyna	Rozwiązanie
`Named Pipes Provider, error: 40 – Could not open a connection to SQL Server`	Port zamknięty na firewallu lub SQL Server nie nasłuchuje na TCP/IP	Sprawdź reguły firewalla; zweryfikuj w Configuration Manager, czy protokół TCP/IP jest włączony
`The target principal name is incorrect. Cannot generate SSPI context`	Problem z rejestracją SPN w Kerberos, często mylnie diagnozowany jako błąd portu	Zarejestruj SPN dla konta usługi; test `Test-NetConnection` na porcie 1433 przejdzie pomyślnie, ale uwierzytelnienie Kerberos zawiedzie
`A network-related or instance-specific error … server not found or not accessible`	Klient nie może rozwiązać nazwy instancji (gdy wyłączony Browser i brak jawnego portu w connection stringu)	Podaj port jawnie: `Serwer,1433` lub `tcp:serwer,1433` w connection stringu

Praktyczne narzędzia diagnostyczne w 2026 roku pozostają niezmienne: Test-NetConnection -ComputerName serwer -Port 1433 (PowerShell), telnet serwer 1433 (tam, gdzie klient Telnet jest jeszcze dostępny), nc -zv serwer 1433 (Linux). Na systemie Linux przydatne jest też ss -tlnp | grep sqlservr, aby zobaczyć, które porty faktycznie nasłuchuje proces sqlservr.

W środowiskach kontenerowych diagnostykę ułatwia docker exec -it <kontener> /opt/mssql-tools/bin/sqlcmd, który pozwala sprawdzić łączność z wnętrza kontenera.

Częste pytania

Czy port 1433 można zmienić na inny?

Tak. Port zmienia się w SQL Server Configuration Manager (Windows) lub przez mssql-conf (Linux). Po zmianie wszystkie connection stringi muszą jawnie podawać nowy numer, a firewall wymaga odpowiedniej reguły. Wiele organizacji celowo zmienia domyślny port, aby utrudnić automatyczne skanowanie, ale jest to bezpieczeństwo przez zaciemnienie — nie zastępuje szyfrowania ani silnego uwierzytelniania.

Czy SQL Server potrzebuje portów UDP oprócz 1434?

W zdecydowanej większości przypadków nie. Silnik bazodanowy komunikuje się przez TCP. UDP 1434 dotyczy wyłącznie SQL Server Browser. Wyjątkiem historycznym są stare protokoły IPX/SPX i VIA, które od SQL Server 2012 zostały usunięte.

Jak sprawdzić, na którym porcie nasłuchuje moja instancja?

Otwórz SQL Server Configuration Manager → SQL Server Network Configuration → Protocols for <instancja> → TCP/IP → zakładka IP Addresses. Alternatywnie, w SQL Server Management Studio przejdź do właściwości serwera i sprawdź ustawienia sieciowe. Na Linuxie uruchom cat /var/opt/mssql/mssql.conf i ss -tlnp | grep sqlservr.

Co z portem dla SQL Server na Azure VM?

Maszyna wirtualna z SQL Server w Azure działa identycznie jak serwer on-premises: porty są takie same. Różnica polega na tym, że reguły firewalla definiuje się dwuwarstwowo: w Network Security Group (NSG) platformy Azure oraz wewnątrz systemu gościa (Windows Firewall lub firewalld). Obie warstwy muszą przepuszczać ruch.

Czy SSMS używa tych samych portów co aplikacja?

Tak. SQL Server Management Studio to standardowy klient TDS (Tabular Data Stream) i łączy się przez te same porty TCP co każda inna aplikacja. Nie ma osobnego portu dla narzędzi administracyjnych — wyjątkiem jest Dedicated Administrator Connection (TCP 1434), dostępna przez sqlcmd -A.

Jakie porty otworzyć dla replikacji transakcyjnej?

Replikacja transakcyjna wymaga dostępu Agenta Dystrybucji do wydawcy i subskrybenta — używa standardowych portów silnika SQL (np. 1433) dla obu połączeń. Dodatkowo folder snapshot (domyślnie udostępniany przez SMB na porcie 445) musi być dostępny między wszystkimi uczestnikami replikacji.

Czy port 1433 wystarczy dla połączeń z Power BI i Azure Data Factory?

Tak, o ile instancja jest domyślna i używa standardowego portu. Dla nazwanej instancji z portem dynamicznym konieczny jest też UDP 1434 (Browser). W praktyce integracyjnej zaleca się stały port i jawne podanie go w connection stringu.

Dlaczego moja aplikacja w kontenerze nie widzi SQL Server?

Najczęstsze przyczyny to: kontener aplikacji i kontener SQL Server nie znajdują się w tej samej sieci Docker (rozwiązanie: docker network create i podłączenie obu kontenerów), connection string wskazuje localhost zamiast nazwy serwisu (powinien wskazywać nazwę kontenera SQL Server), lub port nie jest prawidłowo zmapowany na hoście.

Jak zabezpieczyć porty SQL Server przed atakami z Internetu?

Nigdy nie wystawiaj portu 1433 bezpośrednio na Internet. W 2026 roku standardem jest dostęp wyłącznie przez VPN (WireGuard, IPsec) lub Azure Private Link. Dodatkowo: zawsze włącz szyfrowanie TLS, stosuj uwierzytelnianie Entra ID (Azure AD) zamiast SQL authentication, ogranicz reguły firewalla do konkretnych źródłowych adresów IP i wdróż Azure Defender for SQL do wykrywania podejrzanej aktywności.

Czy muszę otwierać porty dla SQL Server 2025 inaczej niż dla 2022?

Nie. SQL Server 2025 zachowuje kompatybilność sieciową z SQL Server 2022 — wszystkie opisane porty, protokoły i mechanizmy (TCP 1433, UDP 1434, TCP 5022 dla Always On, zakres PolyBase) pozostają bez zmian. Microsoft nie zasygnalizował modyfikacji architektury sieciowej w wersji 2025, a wsteczna kompatybilność protokołu TDS jest fundamentem ekosystemu SQL Server od dwóch dekad.

Sprawdź też

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