SQL Server’a Bağlanılamıyor: Error 26, 40, 53 ve 18456 Hatalarını Adım Adım Çözme

Uygulama sabah açılmıyor, SSMS bağlanmıyor ya da yeni kurulan sunucuya kimse erişemiyor. SQL Server bağlantı hataları çoğu zaman aynı genel mesajla gelir ve mesaj, sorunun nerede olduğunu söylemez. Oysa bağlantının kurulabilmesi için birkaç katmanın sırayla çalışması gerekir: servis ayakta olmalı, istemci doğru instance’ı bulabilmeli, ağ ve güvenlik duvarı izin vermeli, oturum açma bilgisi kabul edilmeli ve yeni sürücülerde şifreleme sertifikası doğrulanabilmeli.

Bu rehberde en sık görülen hataların (26, 40, 53, 10060 ve 18456) hangi katmanı işaret ettiğini ve her birinin nasıl adım adım çözüleceğini anlatıyoruz.

Hata Mesajı Ne Söylüyor?

En sık karşılaşılan mesaj, SSMS’te ya da uygulama loglarında şu şekilde görünür:

Mesajın başı her zaman aynıdır; ipucu parantez içindeki error numarasındadır. Hataları üç gruba ayırmak, nereden başlayacağınızı belirler:

1. SQL Server Servisi Çalışıyor mu?

İlk kontrol en basit olanıdır. SQL Server Configuration Manager’da ya da Windows Hizmetler ekranında Database Engine servisinin (SQL Server (MSSQLSERVER) veya SQL Server (InstanceAdı)) Running durumda olduğunu doğrulayın. Adlandırılmış instance kullanıyorsanız SQL Server Browser servisinin de çalışması gerekir.

PowerShell ile aynı kontrol:

Get-Service -Name 'MSSQL*', 'SQLBrowser' | Select-Object Name, Status, StartType

Servis başlamıyorsa sorun bağlantı değil başlangıçtır; nedeni SQL Server error log’unda ve Windows Application log’undadır. Error log’u nasıl okuyacağınızı error log rehberimizde anlatıyoruz.

2. Doğru Sunucu ve Instance’a mı Bağlanıyorsunuz?

Varsayılan instance’a yalnızca sunucu adıyla (SUNUCU), adlandırılmış instance’a SUNUCU\InstanceAdı biçiminde bağlanılır. Adlandırılmış instance’lar varsayılan olarak dinamik port kullanır; istemci portu SQL Server Browser’a UDP 1434 üzerinden sorarak öğrenir. Browser kapalıysa ya da UDP 1434 engelliyse error 26 alırsınız.

İki kalıcı çözüm vardır: Browser’ı çalıştırıp UDP 1434’e izin vermek ya da instance’a sabit bir port atayıp istemcide portu açıkça yazmak (SUNUCU,1450). Üretim ortamlarında sabit port, güvenlik duvarı kurallarını da öngörülebilir kıldığı için genellikle daha iyi bir seçimdir.

SQL Server’ın gerçekte hangi IP ve portu dinlediğini error log’dan görebilirsiniz:

EXEC sys.xp_readerrorlog 0, 1, N'Server is listening on';

3. TCP/IP Protokolü Açık mı?

SQL Server Express ve Developer kurulumlarında TCP/IP protokolü varsayılan olarak kapalıdır; bu durumda sunucunun kendisinden bağlanabilir, başka bir makineden bağlanamazsınız. SQL Server Configuration Manager’da SQL Server Network Configuration › Protocols for [instance] altında TCP/IP’yi etkinleştirin. Port ayarı da aynı ekranın IP Addresses sekmesindeki IPAll bölümündedir. Değişiklik servis yeniden başlatıldıktan sonra geçerli olur.

4. “Allow Remote Connections” Kutusu Ne İşe Yarar?

Pek çok rehber, sunucu özelliklerindeki Connections sayfasında bulunan Allow remote connections to this server kutusunu işaretlemeyi önerir.

5. Güvenlik Duvarı Portlara İzin Veriyor mu?

Servis çalışıyor, TCP/IP açık ama bağlantı yine zaman aşımına uğruyorsa (10060) en olası neden güvenlik duvarıdır. Varsayılan instance için TCP 1433’e, adlandırılmış instance’larda sabit porta ve SQL Server Browser kullanılıyorsa UDP 1434’e izin verin. Önce istemciden portun erişilebilir olup olmadığını test edin:

# İstemci makineden: port açık mı?
Test-NetConnection -ComputerName SUNUCU -Port 1433

# Sunucuda: SQL Server portu için gelen kuralı
New-NetFirewallRule -DisplayName 'SQL Server TCP 1433' -Direction Inbound `
    -Protocol TCP -LocalPort 1433 -Action Allow -Profile Domain

TcpTestSucceeded : False sonucu sorunun SQL Server’da değil ağda ya da güvenlik duvarında olduğunu gösterir. Sunucu ile istemci arasındaki ağ cihazlarında da aynı portun açık olması gerekir.

6. Login Failed (18456): State Numarası Nedeni Söyler

18456 hatası, bağlantının sunucuya ulaştığını ama oturum açmanın reddedildiğini gösterir. Güvenlik nedeniyle istemciye gönderilen mesaj belirsizdir; asıl neden SQL Server error log’undaki state numarasındadır:

EXEC sys.xp_readerrorlog 0, 1, N'Login failed';

Bir migration ya da restore sonrasında görülen 18456 hatalarının sık nedeni, veritabanındaki kullanıcı ile sunucudaki login’in SID’lerinin eşleşmemesidir (orphaned user). Login’leri yeni sunucuya SID’leriyle birlikte taşımak bu sorunu baştan önler.

7. Sertifika Hataları: Yeni Sürücülerde Şifreleme Varsayılan

ODBC Driver 18, OLE DB Driver 19 ve güncel Microsoft.Data.SqlClient sürümleri bağlantıyı varsayılan olarak şifreler ve sunucu sertifikasını doğrular. Sunucu kendi ürettiği (self-signed) sertifikayı kullanıyorsa bağlantı şu hatayla düşer: “The certificate chain was issued by an authority that is not trusted.” Sürücü güncellemesinden ya da SQL Server 2025’e geçişten sonra aniden ortaya çıkan bağlantı hatalarının önemli bir kısmı bu nedenle oluşur; SQL Server 2025 kurulumuyla gelen sürücüler de bu varsayılanla çalışır.

Linked server’lar da bu değişiklikten etkilenir; ayrıntıları linked server rehberimizde ele alıyoruz.

Bağlantı Sorunu Kontrol Listesi

1. Database Engine servisi ve (adlandırılmış instance’ta) SQL Server Browser çalışıyor.
2. Sunucu adı DNS’te çözülüyor; instance adı ya da port doğru yazılmış.
3. TCP/IP protokolü açık; SQL Server’ın dinlediği port error log’da doğrulandı.
4. Test-NetConnection ile port istemciden erişilebilir.
5. Güvenlik duvarında TCP portu ve gerekiyorsa UDP 1434 açık.
6. 18456 hatalarında error log’daki state numarası incelendi.
7. Yeni sürücülerde sunucu sertifikası güvenilir bir otoriteden alınmış.

Hiçbiri sonuç vermiyorsa ve sunucu yanıt vermiyorsa, sysadmin olarak Dedicated Admin Connection (DAC) ile bağlanıp sunucunun içinde ne olduğuna bakabilirsiniz.