Nextdoor ve Proxy: Neyin Değiştiği, Neyin Değişmediği

Nextdoor, konum doğrulamasına dayanan bir komşuluk ağıdır. Hesap oluşturulurken belirlenen adres ya da bölge, kullanıcının hangi komşuluk akışını göreceğini belirler ve bu bilgi hesabın kendisinde tutulur. Proxy ise bir ağ katmanı aracıdır: isteğin hangi IP adresinden çıktığını değiştirir. Bu iki katmanı ayırmadan yapılan her kurulum, beklentiyle sonucun uyuşmadığı bir noktada takılır.

Buna karşılık çıkış adresinin gerçekten iş gördüğü alanlar vardır: oturum açmadan görüntülenebilen işletme ve bölge sayfalarının okunması, arayüzün hangi dili ve para birimini varsayılan seçtiği, kurumsal bir ağdan çıkarken sabit bir adres kullanma ihtiyacı ve isteğin kaynağının hangi ağ ailesi olarak sınıflandırıldığı.

Aşağıdaki bölümler önce trafiğin kaç parçaya ayrıldığını, sonra herkese açık uç noktalarda istek hızının nasıl sınırlandığını, ardından IP itibarı ile oturum yönetimini ele alıyor. Kurulum ve doğrulama adımları sonda toplanmıştır.

Komşuluk kaydı ile çıkış adresi neden aynı şey değildir?

Bir hesabın hangi mahalleyi gördüğü kayıt sırasında belirlenir ve sonrasında hesap ayarlarından yönetilir. Başka bir ülkedeki çıkış üzerinden bağlandığınızda akışınız o ülkenin mahallelerine dönmez; hesabınızın bağlı olduğu bölge neyse onu görmeye devam edersiniz. Bu, platformun tasarım kararıdır ve proxy ile ilgisi yoktur.

Çıkış adresinin ölçülebilir biçimde etkilediği noktalar daha dardır. Oturum açmadan erişilebilen sayfalarda sunucu, isteği yalnızca IP üzerinden değerlendirir. Arayüzün ilk açılışta hangi dili ve hangi ölçü birimini seçtiği, bazı akışlarda hangi ülkenin varsayılan olarak önerildiği ve isteğin hangi ağ ailesinden geldiği bu değerlendirmenin girdileridir.

Üçüncü nokta teknik ve çoğu kullanıcının gözden kaçırdığı yerdir: sayfa tek bir alan adından gelmez. Sayfa gövdesi ve arka plandaki JSON yanıtları ana alan adına gider, görsel ve betik gibi statik dosyalar bir içerik dağıtım ağından servis edilir, harita ve konum bileşenleri ise çoğu kurulumda ayrı bir servise bağlanır. Proxy kuralınız yalnızca ana alan adını kapsıyorsa geri kalan istekler doğrudan gider.

Herkese açık uç noktalarda istek hızı nasıl sınırlanır?

Oturum gerektirmeyen sayfalar ve arka plandaki JSON çağrıları sınırsız değildir. Sunucu tarafında bir zaman penceresi ve o pencere içinde kabul edilecek istek sayısı tanımlıdır. Pencere dolduğunda istek reddedilir; yaygın karşılık 429 Too Many Requests durum kodudur ve yanıt genellikle ne kadar beklenmesi gerektiğini bildiren bir Retry-After başlığı taşır.

Sınırın tek boyutu istek sayısı değildir. Eşzamanlı açık bağlantı adedi de değerlendirilir; aynı anda onlarca bağlantı açan bir istemci, toplam istek sayısı düşük olsa bile yavaşlatılabilir. Bu konudaki ayrıntılar için eşzamanlı bağlantı limiti yazısı pratik bir çerçeve veriyor.

Doğru davranış, sınırı aşmaya çalışmak değil sınırın içinde kalmaktır. İstekler arasına sabit değil değişken aralık koyun, 429 aldığınızda üstel geri çekilme (exponential backoff) uygulayın ve Retry-After değerini yok saymayın. Yükü birden fazla çıkışa yaymanız gerekiyorsa rotating proxy tarafındaki havuz mantığı işinize yarar; ancak bu, toplam istek bütçesini büyütmenin değil tek bir adrese yüklenmemenin yoludur.

Çıkışınızın hangi ağ ailesinde göründüğü neden önemli?

Her IP adresi bir otonom sisteme (ASN) aittir. ASN, adres bloğunu kimin duyurduğunu söyler: bir ev interneti sağlayıcısı, bir mobil operatör ya da bir barındırma şirketi. Sunucu tarafı bu bilgiyi ucuz ve hızlı bir sinyal olarak kullanır, çünkü tek bir sorguyla adresin hangi aileye girdiğini öğrenir. Konu ayrıntısı için ASN ve IP itibarı yazısına bakabilirsiniz.

Mobil operatör adresleri bu tabloda özel bir yerde durur. Operatörler abone sayısı ile adres sayısı arasındaki farkı CGNAT ile kapatır: çok sayıda gerçek abone aynı genel adresin arkasından çıkar. Bu yüzden tek bir mobil adreste yoğun ve çeşitli trafik görmek olağandır. Mekanizmanın kendisi CGNAT nedir yazısında anlatılıyor.

Veri merkezi adresleri ise tam tersidir: blok sahibi bellidir, adresler kalabalık bir abone kütlesine değil sunuculara aittir ve sınıflandırma nettir. Bu, kötü bir şey anlamına gelmez; oturum açılmayan, herkese açık içeriğin okunduğu ve hızın önemli olduğu işlerde datacenter proxy yeterli ve ekonomiktir.

Seçim yaparken sıralamayı tersten kurun: önce işin oturum açıp açmadığına, sonra hız ve maliyet beklentisine bakın. Oturumsuz bir okuma işine mobil çıkış almak gereksiz maliyettir; buna karşılık uzun süreli tek hesap yönetiminde kararlı bir ISP çıkışı çoğu zaman en dengeli seçenektir.

Oturum çerezi, istemci kimliği ve sabit çıkış üçlüsü

Oturum açılan her senaryoda üç bilgi birlikte hareket eder: tarayıcının taşıdığı oturum çerezi, istemcinin kendini tanıttığı bilgiler (tarayıcı sürümü, dil, saat dilimi, ekran özellikleri) ve isteğin geldiği çıkış adresi. Bu üçü tutarlı olduğunda oturum sakin ilerler; biri diğerlerinden bağımsız değiştiğinde ek doğrulama istekleri görülmeye başlar.

En sık yapılan hata, çıkış adresini her istekte değiştiren bir havuzu oturum açılan işte kullanmaktır. Aynı çerezin kısa aralıklarla farklı ülkelerdeki adreslerden gelmesi tutarsız bir tablodur. Çözüm, belirli bir süre aynı çıkışta kalan sticky oturumdur; kurulumu sticky oturum rehberinde adım adım anlatılıyor.

İkinci hata, tarayıcı profillerini karıştırmaktır. Aynı tarayıcı profilinde birden fazla hesapla çalışmak, çerezlerin ve yerel depolama kayıtlarının birbirine karışmasına yol açar. Her iş için ayrı bir tarayıcı profili açmak, her profili tek bir çıkışa bağlamak ve bu eşleşmeyi not etmek en sade düzendir.

• Bir hesap için tek bir çıkış adresi belirleyin ve bunu gerekmedikçe değiştirmeyin.
• Çıkış ülkesini hesabın olağan kullanım ülkesiyle aynı tutun.
• Aynı anda hem VPN hem proxy çalıştırmayın; iki katman teşhisi imkânsız hâle getirir.
• Çıkış değiştirmeniz gerekiyorsa önce oturumu kapatın, sonra yeni çıkışta yeniden açın.
• Profil–çıkış eşleşmesini yazılı tutun; ekip büyüdüğünde bu liste tek gerçek kaynak olur.