localhost Bağlantıyı Reddetti Hatası Nasıl Çözülür? ERR_CONNECTION_REFUSED

localhost bağlantıyı reddetti hatası ne demek ve hemen ne yapmalısınız?

localhost bağlantıyı reddetti hatası, tarayıcının kendi bilgisayarınızdaki belirli bir porta ulaştığını ama orada bağlantıyı kabul eden hiçbir uygulama bulamadığını gösterir. Sunucu kapalıdır, farklı bir portu dinliyordur ya da başka bir adrese bağlanmıştır. Önce terminali kontrol edin, sonra adres ve portu doğrulayın.

Aşağıdaki sıra, sahada en sık gördüğümüz nedenden en nadire doğru ilerler. Çoğu zaman ilk üç adım sorunu çözer.

1. Uygulamayı başlattığınız terminale bakın ve sunucunun gerçekten çalıştığını, çökmediğini doğrulayın.
2. Terminalde yazan portu adres çubuğundaki portla karşılaştırın.
3. Adresi http://127.0.0.1:PORT olarak deneyin ve sonucu localhost ile kıyaslayın.
4. Adresin başındaki http ve https farkına bakın.
5. Portu başka bir sürecin tutup tutmadığını kontrol edin.
6. Docker, WSL veya sanal makine kullanıyorsanız port eşlemesini inceleyin.
7. Güvenlik duvarı, antivirüs ve tarayıcı önbelleğini en sona bırakın.

Bu yazı yalnızca bu tek hatayı çözer. Komşu sorunlar için ilgili yazılara kısa bağlantılar verdik.

Bu hata mesajı tam olarak neyi anlatıyor?

Tarayıcı, adres çubuğundaki ana makineye ve porta bir bağlantı isteği gönderir. İşletim sistemi o portta dinleyen bir süreç bulamazsa isteği hemen reddeder. Tarayıcı da ERR_CONNECTION_REFUSED koduna benzeyen bir uyarı gösterir. Kesin metin tarayıcıya ve sürüme göre değişebilir, bu yüzden hata kodunu aramak daha güvenlidir.

Burada önemli bir ayrım var. Reddedilen bağlantı, isteğin hedefe ulaştığı ama kapıyı kimsenin açmadığı anlamına gelir. Zaman aşımı ise isteğin hiç yanıt almadığını gösterir. Ağ tarafında bir engel arıyorsanız zaman aşımı daha olasıdır, reddedilme ise neredeyse her zaman uygulama ya da adres sorunudur.

Dolayısıyla internet bağlantınızı yenilemenin, DNS önbelleğini temizlemenin veya modemi yeniden başlatmanın bu hatayla ilgisi yoktur. Trafik zaten dışarı çıkmıyor, kendi makinenizin içinde kalıyor.

localhost bağlantıyı reddetti hatasında teşhis sırası nasıl olmalı?

Spesifik yaklaşımımız şudur: önce şunu kontrol edin, çünkü en sık neden bu. Teşhisi tahmine değil, sonuca bağlayın. Her adım bir sonraki adımı gereksiz kılabilir.

Örnek senaryo: bir ekip arkadaşınız ön yüz projesini açıyor ve tarayıcıda localhost bağlantıyı reddetti uyarısı görüyor. Terminalde sunucunun başladığına dair bir satır yok. Bu durumda port, adres ve Docker kontrollerine hiç gerek kalmaz. Çünkü sunucu zaten çalışmıyor.

• Terminal çıktısı: sunucu başladı mı, hata verip kapandı mı?
• Port numarası: yazdığınız port ile uygulamanın dinlediği port aynı mı?
• Dinleme adresi: uygulama yalnızca IPv4 mü, yalnızca IPv6 mı, yoksa ikisini birden mi dinliyor?
• Protokol: http mi, https mi?
• Çakışma: portu başka bir süreç mi tutuyor?
• Ortam: Docker, WSL veya sanal makine araya giriyor mu?

Kısacası, her adımda tek bir değişkeni değiştirin ve sonucu not edin. Aynı anda üç şeyi değiştirirseniz hangisinin işe yaradığını bilemezsiniz.

Sunucu gerçekten çalışıyor mu?

En sık neden basittir: sunucu hiç başlamamıştır ya da başladıktan sonra çökmüştür. Tarayıcı bu durumda tam olarak yukarıdaki hatayı verir. Terminali kapatmak, bilgisayarı yeniden başlatmak veya bir bağımlılık hatası yüzünden süreç sonlanmış olabilir.

Uygulamayı başlattığınız pencereye dönün. Kırmızı bir hata, yakalanmamış bir istisna veya komutun hemen geri dönmesi, sunucunun ayakta olmadığını gösterir. Ayrıca bazı çerçeveler sunucuyu başlattığını açıkça yazar ve dinlediği adresi gösterir. Bu satırı bulamıyorsanız sorun tarayıcıda değildir.

Bir de izleyici modunda çalışan araçlar var. Dosya kaydettiğinizde sunucu kendini yeniden başlatır, yeniden başlatma sırasında bir söz dizimi hatası varsa süreç düşer. Böylece birkaç saniye önce çalışan adres bir anda reddetmeye başlar.

Çalışıp çalışmadığını tarayıcı dışında da sınayabilirsiniz. Terminalde şu komut, sunucunun yanıt verip vermediğini gösterir:

curl -v http://127.0.0.1:3000

Burada 3000 yalnızca örnek bir porttur, kendi portunuzu yazın. Komut bağlantı reddedildi diyorsa sorun gerçekten sunucu tarafındadır. Yanıt alıyorsanız tarayıcı önbelleği veya adres çözümü devreye girmiştir.

Doğru portu mu açıyorsunuz?

İkinci sık neden port uyuşmazlığıdır. Çerçeveler varsayılan olarak farklı portlar kullanır ve proje ayarı ya da ortam değişkeni bunu değiştirebilir. Siz alışkanlıkla eski portu yazarsınız, uygulama ise yenisinde bekler.

Terminaldeki başlangıç satırı bu konuda en güvenilir kaynaktır. Orada yazan adresi kopyalayıp tarayıcıya yapıştırın. Elle yazmak yerine kopyalamak, yazım hatasını da eler.

• Aynı projeyi iki terminalde başlattıysanız ikinci kopya otomatik olarak başka bir port seçmiş olabilir.
• Ortam dosyasındaki port değeri, kod içindeki varsayılan değeri ezer.
• Eski bir yer imi veya geçmiş kaydı artık kullanılmayan bir portu gösterebilir.
• Bir ekip arkadaşınızın verdiği adres, kendi makinenizde farklı bir porta denk gelebilir.

Ayrıca yönlendirme yapan bir ters vekil kullanıyorsanız, dışarıdaki port ile uygulamanın portu farklı olur. Yerelde ise doğrudan uygulamanın portuna gitmeniz gerekir.

Uygulama hangi adrese bağlı: 127.0.0.1, 0.0.0.0 ve ::1 farkı nedir?

Bir sunucu yalnızca bağlandığı adresten gelen bağlantıları kabul eder. 127.0.0.1 yalnızca kendi makinenizin IPv4 geri döngü adresidir. ::1 aynı işin IPv6 karşılığıdır. 0.0.0.0 ise tüm IPv4 arayüzlerini dinlemek anlamına gelir.

Node.js belgelerine göre, ana makine belirtmeden dinlemeye başlayan bir sunucu IPv6 varsa belirtilmemiş IPv6 adresini, yoksa belirtilmemiş IPv4 adresini dinler. Birçok işletim sisteminde IPv6 üzerinden dinlemek IPv4'ü de kapsar, ancak bu davranış her yerde aynı değildir. Ayrıntı için Node.js net belgesine bakın.

Pratik sonuç şudur: uygulama yalnızca 127.0.0.1 üzerinde dinliyorsa ve tarayıcı localhost adını ::1 olarak çözerse, bağlantı reddedilir. Tersi de mümkündür. Uygulama yalnızca ::1 dinler, istemci ise IPv4 dener.

Bu yüzden iki adresi de elle deneyin. http://127.0.0.1:PORT çalışıp http://localhost:PORT çalışmıyorsa, adres çözümü ile dinleme adresi uyuşmuyor demektir. Çözüm, uygulamayı hem IPv4 hem IPv6 dinleyecek biçimde başlatmak ya da adresi açıkça 127.0.0.1 yazmaktır.

localhost neden IPv6 adresine çözülür ve bu neden hataya yol açar?

localhost bir ağ adresi değil, bir addır. İşletim sistemi bu adı hosts dosyasındaki kayıtlara göre hem 127.0.0.1 hem ::1 olarak çözebilir. Hangisinin önce denendiği, istemcinin ve yazılım sürümünün davranışına bağlıdır.

Node.js belgelerinde adres çözümleme sırasının, yeni sürümlerde işletim sisteminin döndürdüğü sıraya göre korunabildiği anlatılır. Eski sürümlerle çalışırken IPv4 öne alınıyordu. Dolayısıyla bir projeyi yeni bir Node.js sürümüne taşıdığınızda, daha önce sorunsuz çalışan localhost adresi bir anda reddetmeye başlayabilir. Güncel davranış için Node.js dns belgesini kontrol edin.

Bu durumu anlamanın en kolay yolu iki adresi karşılaştırmaktır. IPv4 çalışıyor, localhost çalışmıyorsa nedeni büyük olasılıkla budur. IPv6 ile ilgili genel kavramlar için IPv6 nedir yazımıza göz atabilirsiniz.

Üstelik ağınızın IPv6 desteğini ücretsiz IPv6 testi aracımızla görebilirsiniz. Ancak bu araç dışarıdan bağlantıyı ölçer, yerel geri döngüyü ölçmez. Yerel için hosts dosyasına ve uygulamanın dinleme adresine bakın.

http ve https karıştırılırsa localhost ne yapar?

Sunucunuz düz http dinliyorsa ve siz adresin başına https yazarsanız, bağlantı kurulamaz ya da sertifika hatası görürsünüz. Çoğu zaman da tarayıcı reddedilen bağlantı uyarısını gösterir. Aynı port iki protokolü birden konuşmaz.

Bazı geliştirme araçları varsayılan olarak https açar, bazıları açmaz. Bir ayarı değiştirdiğinizde protokol de değişir. Adres çubuğuna elle yazmak yerine terminalin verdiği adresi kullanın.

Adres çubuğunda başka bir tuzak daha var. Tarayıcılar adresi tamamlarken önceki ziyaretinizi hatırlayabilir. Örneğin geçen hafta https ile açtığınız adres, bu hafta http ile başlayan uygulamanız için otomatik olarak https önerir. Bu durumda adresi baştan, protokolüyle birlikte yazın.

Güvenli bağlantı gerektiren bir özelliği yerelde denemek istiyorsanız, sertifikayı yerel geliştirme için üreten araçlar kullanabilirsiniz. Üretimdeki sertifika konusu için SSL sertifikası yazımızı okuyun.

Port başka bir süreç tarafından mı kullanılıyor (EADDRINUSE)?

Aynı portu iki süreç aynı anda dinleyemez. Portu zaten bir süreç tutuyorsa yeni uygulamanız başlarken EADDRINUSE benzeri bir hata verir ve kapanır. Siz de kapanmış sunucuya bağlanmaya çalışınca bağlantı reddedilir.

Tabloda iki ayrı senaryo var. Birinci senaryoda eski bir süreç portu tutmaya devam eder ve yeni sunucu hiç başlamaz. İkinci senaryoda eski süreç asılı kalmıştır, tarayıcı eski ve bozuk bir uygulamayla konuşur.

Terminaldeki ilk kırmızı satıra bakın. Orada portun kullanımda olduğunu belirten bir ifade varsa, sorun başka bir süreçte demektir. Önceki oturumu kapatmayı unuttuysanız, arka planda çalışan eski kopya portu tutuyor olabilir.

Bu hata sınıfı yalnızca yerelde görülmez. Üretimde süreç yöneticisi kullanıyorsanız, PM2 ile Node.js uygulamalarını yönetme yazımız aynı portun iki kez başlatılmasını nasıl önleyeceğinizi anlatıyor.

Portu kullanan süreci nasıl bulursunuz?

İşletim sistemi her dinleyen portu ve sahibini listeleyebilir. Komutlar sistemden sisteme değişir, ama mantık aynıdır: portu seçin, sahibini bulun, gerekirse süreci sonlandırın.

• macOS ve Linux: lsof -i :3000 komutu portu tutan süreci ve numarasını gösterir.
• Linux: ss -ltnp dinleyen tüm TCP portlarını listeler.
• Windows: netstat -ano çıktısında portun yanındaki son sütun süreç numarasını verir.

Süreç numarasını bulduktan sonra, hangi uygulamaya ait olduğunu görev yöneticisinden veya etkinlik izleyicisinden kontrol edin. Tanımadığınız bir sistem sürecini sonlandırmayın. Kendi eski geliştirme sunucunuzsa kapatabilirsiniz.

Alternatif olarak uygulamanızı farklı bir portta başlatın. Çoğu çerçeve port numarasını ortam değişkeninden veya komut satırı seçeneğinden alır. Böylece çakışmayı çözmeden önce çalışır duruma gelirsiniz. Kalıcı çözüm için ise eski süreci neden kapatmadığınızı bulun.

Docker kullanıyorsanız localhost bağlantıyı reddetti hatası neden çıkar?

Docker'da uygulama konteynerin içinde çalışır ve konteynerin kendi ağ alanı vardır. Tarayıcınız ise ana makinededir. Aradaki köprü, port yayınlama ayarıdır. Bu ayar olmadan localhost bağlantıyı reddeder.

Docker belgeleri, bir portu ana makineye açmak için konteyneri çalıştırırken port yayınlamanın gerektiğini anlatır. Genel biçim ana makine portu ve konteyner portu ikilisidir:

docker run -p 8080:3000 imaj-adi

Bu örnekte tarayıcıda 8080 yazarsınız, konteyner ise içeride 3000'i dinler. Ayrıntılar için Docker port yayınlama belgesine bakın.

• Dockerfile içindeki EXPOSE satırı portu yayınlamaz, yalnızca bilgi verir.
• Konteynerin içindeki uygulama yalnızca 127.0.0.1 dinliyorsa, dışarıdan gelen istek ona ulaşmaz. Uygulamanın tüm arayüzleri dinlemesi gerekir.
• Çalışan konteynerlerin port eşlemesini görmek için docker ps çıktısındaki portlar sütununa bakın.

Docker'ı yeni öğreniyorsanız önce Docker nedir ve konteyner rehberi yazımızı okuyun. Veritabanı konteynerleri için de Docker ile PostgreSQL ve MySQL kurulumu yazımız aynı port mantığını gösteriyor.

WSL ve sanal makinelerde localhost nasıl davranır?

WSL veya sanal makine kullandığınızda uygulama başka bir işletim sisteminin içinde çalışır. Tarayıcı ise çoğunlukla ana sistemde açıktır. Yani localhost, tarayıcının bulunduğu makineyi gösterir, uygulamanın bulunduğu makineyi değil.

Bazı kurulumlarda ana sistem, sanal ortamdaki portları otomatik olarak yönlendirir. Bazılarında yönlendirme yoktur ve sanal makineye kendi IP adresiyle gitmeniz gerekir. Bu davranış sürüme, ağ kipine ve ayara göre değişir. Dolayısıyla kendi kurulumunuzun resmi belgesini kontrol edin.

• Uygulamanın sanal ortamdaki dinleme adresini kontrol edin.
• Sanal makinenin ağ kipini (köprü, NAT, yalnızca ana makine) doğrulayın.
• Gerekiyorsa sanal makine ayarlarında port yönlendirme kuralı ekleyin.
• Tarayıcıyı da sanal ortamın içinde açarak sorunu yalıtın. Orada çalışıyorsa sorun ağ geçişindedir.

Uzak bir sunucuda çalıştırıp kendi bilgisayarınızdan localhost ile açmaya çalışıyorsanız, bu da aynı sorundur. Uzak sunucunun localhost'u, sizin bilgisayarınızın localhost'u değildir. Bunun için ya sunucunun gerçek adresini kullanın ya da güvenli bir port yönlendirme tüneli kurun.

Node.js, Python veya PHP sunucusunda localhost bağlantıyı reddetti hatası farklı mı görünür?

Tarayıcı açısından fark yoktur, hepsi aynı uyarıyı gösterir. Fark, sunucunun varsayılan dinleme adresinde ve başlangıç mesajındadır. Bu yüzden her çerçevenin kendi belgesini kontrol etmek gerekir.

Bazı yerel geliştirme sunucuları güvenlik gerekçesiyle yalnızca geri döngü adresini dinler. Bazıları ise ağdaki diğer cihazlara açılmak için tüm arayüzleri dinler. Aynı proje iki farklı makinede farklı davranıyorsa, nedeni genellikle bu varsayılandır.

• Başlangıç komutuna adres seçeneği eklenebiliyorsa adresi açıkça yazın.
• Ortam değişkeniyle port ve adres veriyorsanız, değişkenin gerçekten okunduğunu terminal çıktısından doğrulayın.
• Hata ayıklama modu ile üretim modu farklı adreste çalışabilir; hangi kipte açtığınıza bakın.
• Birden fazla proje çalıştırıyorsanız her birine ayrı port verin.

Örneğin bir ekip arkadaşınız aynı kodu başka bilgisayarda sorunsuz açıyorsa, iki makinenin Node.js veya Python sürümünü karşılaştırın. Sürüm farkı adres çözümlemesini değiştirebilir. Böylece sorunun kodda değil ortamda olduğunu hızlıca anlarsınız.

Nginx gibi bir ters vekil kullanıyorsanız ne değişir?

Ters vekil, gelen isteği arkadaki uygulamaya iletir. Arkadaki uygulama kapalıysa vekil size 502 benzeri bir yanıt döner. Vekilin kendisi kapalıysa ise tarayıcıda yine bağlantı reddedilir.

Yerel geliştirmede vekil nadiren gerekir. Yine de üretime benzer bir ortam kuruyorsanız iki katmanı ayrı ayrı sınayın. Önce uygulamanın portuna doğrudan gidin, ardından vekilin portuna gidin. Hangisinde hata başlıyorsa sorun o katmandadır.

Dolayısıyla vekil yapılandırmasında yazan arka uç adresi ile uygulamanın gerçek dinleme adresi birebir uyuşmalıdır. Örneğin vekil 127.0.0.1 adresine yönlendirirken uygulama yalnızca ::1 dinliyorsa istek reddedilir. Üretimde karşılaşılan benzer bir tabloyu 502 Bad Gateway hatası yazımızda anlattık.

Üç dakikada teşhis nasıl görünür? Örnek senaryo

Aşağıdaki akış tamamen bir örnek senaryodur, gerçek bir müşteri vakası değildir. Amaç, sıranın pratikte nasıl işlediğini göstermektir.

Bir geliştirici projeyi açar, tarayıcıda localhost bağlantıyı reddetti uyarısını görür. İlk adımda terminale bakar ve sunucu başlangıç satırını görür. Sunucu çalışıyor, o hâlde nedeni başka yerde aramak gerekir.

İkinci adımda terminaldeki portu adres çubuğuyla karşılaştırır ve ikisinin aynı olduğunu görür. Üçüncü adımda curl ile 127.0.0.1 adresini dener, yanıt gelir. Ardından localhost adresini dener, bağlantı reddedilir.

Sonuç açıktır: localhost adı IPv6 adresine çözülüyor, uygulama ise yalnızca IPv4 dinliyor. Geliştirici adresi 127.0.0.1 olarak yazar ve işini sürdürür. Kalıcı çözüm için başlangıç ayarına dinleme adresini ekler. Böylece tüm süreç birkaç dakika sürer ve hiçbir ayarı rastgele değiştirmesi gerekmez.

Güvenlik duvarı veya antivirüs bağlantıyı engelliyor olabilir mi?

Evet, ama düşündüğünüzden daha az sıklıkla. Geri döngü trafiği genellikle güvenlik duvarının dışında kalır. Yine de bazı kurumsal güvenlik yazılımları yerel portlara erişimi kısıtlar.

Bu nedenle bu adımı listenin sonuna bıraktık. Önce uygulamanın ve adresin doğru olduğundan emin olun. Ardından güvenlik yazılımını suçlayın.

• Güvenlik yazılımının kayıtlarında engellenen bağlantı var mı bakın.
• Kurumsal bir cihazdaysanız BT yönetiminin politikasını sorun.
• Güvenlik duvarını tamamen kapatmak yerine, geliştirme sunucunuza özel bir izin kuralı ekleyin.
• Test için geçici olarak kapatırsanız işiniz biter bitmez açın.

Ayrıca tarayıcı eklentileri de yerel adreslere gidişi bozabilir. Gizli pencerede, eklentisiz açarak deneyin. Çalışıyorsa sorun eklentidedir.

Sunucu tarafındaki güvenlik duvarı kavramlarını merak ediyorsanız CSF firewall yazımıza bakabilirsiniz. Ancak yerel geliştirme için bu çoğunlukla gerekmez.

Tarayıcı önbelleği ve HSTS localhost hatasını nasıl etkiler?

Tarayıcı bazen önceki yanıtı veya yönlendirmeyi hatırlar. localhost için daha önce kalıcı bir https yönlendirmesi gördüyse, artık http ile açmanıza izin vermeyebilir. Sonuç, hâlâ reddedilen bir bağlantıdır.

HSTS, bir sitenin tarayıcıya yalnızca https ile bağlanmasını söylemesidir. Aynı adres daha önce bu başlığı gönderdiyse, tarayıcı sonraki http isteklerini kendisi https yapar. Ayrıntıyı MDN HSTS belgesinde görebilirsiniz.

• Gizli pencerede aynı adresi deneyin. Çalışıyorsa sorun önbellekte veya kayıtlı ilkededir.
• Başka bir tarayıcıyla deneyin.
• Tarayıcının site verilerini yalnızca localhost için temizleyin.
• HSTS kaydı kalıcıysa, tarayıcının alan adı güvenlik ilkeleri bölümünden localhost kaydını silin.
• Yerel geliştirmede HSTS başlığını hiç göndermeyin.

Özetle, önbellek nedeni ender görülür ama ortaya çıktığında kafa karıştırır. Terminal ve curl çıktısı temizse, ama tarayıcı hâlâ reddediyorsa bu kaydı şüphelenin.

Hosts dosyası localhost adını bozmuş olabilir mi?

Evet, olabilir. localhost adı, işletim sisteminin hosts dosyasındaki kayıtlarla geri döngü adresine bağlanır. Dosyayı elle düzenlediyseniz veya bir araç sizin yerinize değiştirdiyse, ad beklenmedik bir adrese çıkabilir.

Dosyada localhost için genellikle bir IPv4 satırı ve bir IPv6 satırı bulunur. Satırlardan biri silinmişse, istemci her seferinde yanlış adresi dener. Başka bir satırda localhost adı farklı bir IP'ye yönlendirilmişse, istek kendi makinenize hiç gelmez.

• Dosyada localhost geçen satırları açıp okuyun.
• Aynı adın birden fazla satırda tanımlı olup olmadığına bakın.
• Yorum satırı yaptığınız kayıtları geri açın.
• Değişiklikten sonra tarayıcıyı tamamen kapatıp yeniden açın.

Yine de bu neden, listede alt sıralarda yer alır. Terminal, port ve dinleme adresi doğruysa ve 127.0.0.1 çalışıyorsa, hosts dosyasına bakmak mantıklıdır. Ayrıca bir VPN veya yerel DNS aracı bu davranışı değiştiriyor olabilir.

Hangi belirti hangi nedene işaret eder?

Aşağıdaki tablo teşhisi hızlandırmak için hazırlandı. Belirtiyi bulun, nedeni ve ilk kontrolü uygulayın. Sıralama en olasıdan en az olasıya doğrudur.

Bu hata CORS, zaman aşımı veya bellek hatalarından nasıl ayrılır?

Benzer görünen ama farklı çözümleri olan hatalar var. Yanlış kapıyı çalmamak için ayırt etmek gerekir.

• Bağlantı reddedildi: İstek hedefe ulaştı, dinleyen yok. Bu yazının konusu budur.
• Zaman aşımı: İstek yanıt almadı. Ağ, yönlendirme veya güvenlik duvarı sorunudur.
• CORS hatası: Sunucu yanıt verdi, ama tarayıcı başka bir kaynağın isteğini engelledi. Çözüm için CORS hatası nasıl çözülür yazımıza bakın.
• Bellek hatası: Sunucu başlamadan veya çalışırken bellek yetmediği için çöktü. Bu durumda JavaScript heap out of memory yazımız işinize yarar.

Dolayısıyla tarayıcıda gördüğünüz ilk cümleye değil, ağ sekmesindeki ve terminaldeki ayrıntıya bakın. Sunucu hiç yanıt vermediyse CORS ile uğraşmak zaman kaybıdır. Yanıt geldiyse reddedilen bağlantıyı aramak yanlıştır.

Genel hata ayıklama alışkanlıkları için hata ayıklama teknikleri yazımızı da öneririz.

Kalıcı önlem için hangi alışkanlıkları edinmelisiniz?

Aynı hatayı ayda bir kez görüyorsanız sorun sizde değil, düzende demektir. Birkaç küçük alışkanlık çoğu tekrarı bitirir.

• Port numarasını proje belgesine ve ortam dosyası örneğine yazın, herkes aynı değeri kullansın.
• Sunucu başlangıç mesajına adresi ve portu yazdıran bir satır ekleyin.
• Dinleme adresini açıkça belirtin; varsayılana güvenmeyin.
• Çalışan geliştirme sunucularını işiniz bitince kapatın.
• Docker kullanıyorsanız port eşlemesini bir yapılandırma dosyasında tutun, komut satırında değil.
• Takımınızda aynı Node.js sürümünü kullanın; adres çözümleme farkları böylece azalır.

Ayrıca yerel ortamı yeni kuran bir geliştirici için kısa bir kontrol listesi hazırlamak, sorunu ilk gün çözer. Üretim ortamına geçerken de aynı mantık geçerlidir. Node.js uygulamasını Linux sunucuya taşıyorsanız Node.js kurulumu ve Nginx ile yayına alma yazımızı izleyin.

Sorun çözülmediyse son kontrol listesi nedir?

Yukarıdaki adımların hepsini uyguladınız ve hata sürüyorsa, listeyi baştan ve sırasıyla tekrar edin. Çoğu zaman bir adım yüzeysel geçilmiştir.

1. Terminalde sunucunun çalıştığını ve hata vermediğini doğrulayın.
2. Yazdığınız port ile terminaldeki port aynı mı, kontrol edin.
3. curl ile 127.0.0.1 adresini deneyin.
4. localhost adresini ayrıca deneyin ve sonucu karşılaştırın.
5. Adresin http veya https olduğuna bakın.
6. Portu kullanan süreci bulun.
7. Docker, WSL veya sanal makine eşlemesini kontrol edin.
8. Gizli pencerede ve başka bir tarayıcıda deneyin.
9. Güvenlik yazılımı kayıtlarına bakın.

Listeyi uygularken bulduklarınızı yazıya dökmek de işe yarar. Hangi adrese, hangi portla gittiğinizi ve ne yanıt aldığınızı kısa notlarla kaydedin. Böylece localhost bağlantıyı reddetti uyarısı bir sonraki sefer çıktığında, aynı adımları baştan düşünmek zorunda kalmazsınız. Üstelik ekip arkadaşlarınız da aynı notlardan faydalanır.

Hâlâ çözüm yoksa hata mesajını, terminal çıktısını ve kullandığınız ortamı tek bir yerde toplayın. Bu üçü bir arada, başka birinin size yardım etmesini çok kolaylaştırır.

Geliştirme ortamı sorunları için ne zaman profesyonel destek almalısınız?

Tek seferlik bir port sorunu için dışarıdan yardım gerekmez. Ancak ekibinizde bu tür kesintiler sık tekrarlıyorsa, sorun süreçte olabilir. Standart olmayan kurulumlar, belgelenmemiş portlar ve herkesin farklı çalıştığı ortamlar zaman kaybettirir.

Talha Aslan ve ekibi olarak özel yazılım projelerinde geliştirme ortamının tekrarlanabilir kurulmasına önem veriyoruz. Projeniz için kapsam ve bütçe görmek isterseniz özel yazılım geliştirme hizmet sayfamızdan teklif isteyin.

Not: Bu yazı genel bir teşhis rehberidir. Kurumsal ağlarda veya yönetilen cihazlarda güvenlik politikaları farklı olabilir, ilgili BT ekibine danışın.