Nodetonet trafiği nasıl yönlendirir — tek bir isteğin tam yolu

curl'e bir Nodetonet bağlantı dizgisi yapıştırıp enter'a bastığınızda, o tek isteği iletmek için altı farklı sistem koordineli çalışır. Her hop birkaç milisaniye ekler; birlikte gecikme, güvenilirlik ve hedeflerin gerçekte hangi IP'yi gördüğünü belirleyen bir zincir oluştururlar. Bunu anlamak "çalışıyor, gönder" ile "gecikme neden 800 ms'ye fırladı, hiçbir fikrim yok" arasındaki farktır.

Bu yazı, tek bir HTTPS GET isteğinin başından sonuna tam yolunu — her hop'taki gerçek wire formatıyla birlikte — anlatıyor ve ardından neyi kontrol edebileceğinizi, neyi edemeyeceğinizi açıklıyor.

Beş hop'luk veri yoluna genel bakış

Her isteğin izlediği tam güzergah:

  +-----------+
  |  İstemci  |  (scraper'ınız / tarayıcı / Postman)
  +-----+-----+
        |  1) sub42.nodetonet.com:48888'e TCP bağlantısı
        v
  +------------+
  | Cloudflare |  2) Anycast PoP — TLS sonlandırma (HTTPS) veya ham iletim
  +-----+------+
        |  3) Fiziksel edge sunucusuna TCP iletimi
        v
  +------------------+
  |  Edge sunucu     |  4) Auth kontrolü, sticky lookup, cihaz seçimi
  | (socks5Server)   |  5) JSON frame kalıcı WebSocket'e itilir
  +-----+------------+
        |  Her zaman açık TLS WebSocket (cihaz panele çevirir)
        v
  +-----------+
  |   Cihaz   |  6) Frame'i aç, hedefe TCP aç
  | (Android) |
  +-----+-----+
        |
        v
  +-----------+
  |   Hedef   |  (api.ipify.org, instagram.com vb.)
  +-----------+

Hop 1 — istemciden Cloudflare'e

Aracınız, sub42.nodetonet.com gibi bir hostname'e ve 48888 gibi bir proxy portuna TCP bağlantısı açar. Bu hostname DNS üzerinden bir Cloudflare anycast adresine çözümlenir; yani TCP SYN paketi istemcinize fiziksel olarak en yakın Cloudflare noktasına (PoP) düşer. Frankfurt'ta bir scraper çalıştırıyorsanız bu genellikle FRA PoP'tur; Singapur'daysanız SIN olur.

HTTPS proxy'lerde TLS Cloudflare edge'inde sonlanır — kimlik bilgileriniz Nodetonet altyapısına ulaşmadan önce bile şifreli bir kanaldan geçer. Ham HTTP ve SOCKS5 için Cloudflare Spectrum, bayt akışını parse etmeden iletir; böylece uçtan uca TCP korunmuş olur.

Hop 2 — Cloudflare'den edge sunucusuna

Cloudflare, TCP akışını proxy oluşturma sırasında 48888 portunun atandığı fiziksel edge sunucusuna iletir. Gecikme sorunlarını incelerken insanların en çok unuttuğu hop budur. Scraper'ınız Berlin'deyse ama edge sunucunuz Singapur'daysa, her istek Avrasya'yı iki kez geçer — bir kez giderken, bir kez dönüşte. Hedefinize değil, istemcinize en yakın edge sunucuyu seçmek, elinizde olan en büyük gecikme kolunuzdur. Bkz. doğru edge sunucusunu seçmek.

Nodetonet edge sunucuları, veri-düzlemi mantığını panelden bağımsız olarak çalıştırır. Bu, panel web arayüzünde kısa bir kesinti yaşansa bile cihazların tünel trafiğini sürdürebildiği anlamına gelir. Edge ve panel, her proxy baytı için değil, yapılandırma için ayrı bir dahili kanal üzerinden iletişim kurar.

Hop 3 — auth, sticky lookup ve cihaz seçimi

Edge sunucusu socks5Server adlı bir süreç çalıştırır (adına karşın aynı port üzerinden HTTP, HTTPS ve SOCKS5'i işler). Yeni bir bağlantı geldiğinde, herhangi bir bayt iletilmeden önce senkron olarak üç şey gerçekleşir:

1. Auth. Proxy kullanıcı adı ve şifresi, kayıtlı proxy kaydıyla eşleştirilir. Müşteri başına kimlik bilgileri ve IP izin listeleri burada uygulanır — eşleşmeyen bir kimlik bilgisi anında 407 döner.
2. Sticky lookup. Proxy'de sticky oturumlar etkinse, panel oturum anahtarını — kullanıcı adındaki -session-XXXX ekinden, bir başlıktan veya kaynak IP'den türetilmiş — hash'ler ve belirli bir cihaza zaten bağlama olup olmadığını kontrol eder. Varsa, bu isteği yalnızca o cihaz karşılamalıdır. Tüm ayrıntı için sticky oturumlar açıklandı.
3. Cihaz seçimi. Sticky bağlama yoksa panel, yapılandırmaya bağlı olarak round-robin veya en-az-bağlantı yöntemiyle token grubundan bir cihaz seçer. Hiçbir cihaz çevrimiçi değilse bağlantı temiz bir 502 ile reddedilir — takılma veya zaman aşımı olmaz. Bkz. round-robin cihaz seçimi nasıl çalışır.

Müşteri başına kontroller — kota, iş parçacığı limiti, son kullanma tarihi, etki alanı izin/reddi — de bu aşamada değerlendirilir. Bir istemci kota sınırına veya iş parçacığı tavanına ulaşmışsa, yeni bağlantı herhangi bir trafik akmadan reddedilir.

Hop 4 — cihaza WebSocket tüneli

Eşleştirilmiş her Android cihaz, edge sunucusuna kalıcı bir TLS WebSocket'i her zaman açık tutar. Panel cihazın çevrimiçi olduğunu bu sayede bilir — soket düştüğü anda yeşil nokta kapanır. Panel hiçbir zaman cihaza bağlanmak zorunda kalmaz; cihaz bağlanır ve kanalı canlı tutar.

Cihaz seçildiğinde edge sunucu, bu mevcut bağlantıya küçük bir JSON komut frame'i iter:

{"op":"connect","cid":"a3f","host":"api.ipify.org","port":443}

İstemciden gelen sonraki baytlar veri frame'leri olarak sarılır:

{"op":"data","cid":"a3f","b64":"..."}

Cihaz simetrik olarak yanıt verir; edge sunucu çözer ve istemci TCP soketine geri yazar. Bu sarmalama, birden fazla eşzamanlı isteğin çoğullanan bağlantı ID'leri (cid değerleri) üzerinden aynı WebSocket'i paylaşabileceği anlamına gelir; bu da yüksek eş zamanlılıkta bile bağlantı yükünü düşük tutar.

Her zaman açık WebSocket aynı zamanda otomatik yük devretmenin neden çalıştığının nedenidir — panel hangi cihazların canlı soketlere sahip olduğunu gerçek zamanlı görebilir ve tarafınızdaki bir TCP zaman aşımını beklemeden düşen bir telefonu atlayabilir.

Hop 5 — cihazdan hedefe

Android cihaz, connect frame'inde belirtilen hedef host ve porta normal bir giden TCP soketi açar. Kilit nokta: TCP bağlantısı cihazın mobil hücresel arayüzünden kaynaklanır; dolayısıyla hedef site, operatör seviyesi NAT üzerinden atanmış gerçek bir mobil operatör IP'si görür. Bu IP, aynı ağdaki gerçek birçok abone tarafından paylaşılır ve bu yüzden yüksek güven puanı taşır.

Bu hop'ta uygulanan opsiyonel özellikler:

• TCP/IP parmak izi sahteciliği — cihaz, hedef OS parmak izini taklit etmek için TCP pencere boyutlarını, TTL'yi ve diğer yığın parametrelerini ayarlayabilir. Bkz. TCP parmak izi sahteciliği.
• Upstream yönlendirme — cihaz kendi SIM IP'sini kullanmak yerine sağladığınız harici bir residential veya backconnect upstream sağlayıcısına trafik iletebilir. Bkz. upstream residential yönlendirme.
• Coğrafi ve operatör hedefleme — hop 3'te seçilen cihaz, kullanıcı adına eklediğiniz değiştiricilerle (-country-tr, şehir etiketi, operatör adı) kontrol edilen belirli bir ülke, şehir ve operatöre sahiptir. Bkz. coğrafi hedefleme.

Hedeften gelen yanıt tam olarak aynı zincirden tersine akar: cihaz soketi → WebSocket frame'i → edge sunucu → Cloudflare → istemci.

Neyi kontrol edebilirsiniz, neyi edemezsiniz

Nodetonet proxy'sinden geçen bir isteğin toplam gidiş-dönüş süresi dört ağ bacağının toplamıdır: istemci → Cloudflare + Cloudflare → edge + edge → cihaz + cihaz → hedef. Herhangi bir bacağı kaldırmak mümkün değildir — her biri gerçek bir amaca hizmet eder. Ancak dördünden üçünü kontrol edersiniz:

• İstemci → Cloudflare: kontrol edilemez — Cloudflare anycast her zaman otomatik olarak en yakın PoP'a yönlendirir.
• Cloudflare → edge: edge sunucu seçiminizle kontrol edilir. Scraper'ınızın veya otomasyonunuzun çalıştığı yere en yakın edge'i seçerek bu bacağı kısa tutun.
• Edge → cihaz: token grubuna atadığınız cihaz havuzuyla dolaylı olarak kontrol edilir; edge ile aynı LAN'daki cihazlar bu bacağı kısaltır ancak çoğu dağıtımda cihaz dünyanın herhangi bir yerindeki bir telefondur.
• Cihaz → hedef: coğrafi hedefleme seçiminizle kontrol edilir. Hedef ile uyumlu ülke ve operatördeki cihazları seçin.

Proxy'lerinizin gerçekte hangi IP'leri ve gecikmeleri sunduğunu incelemek isterseniz ücretsiz proxy checker aracımızı veya proxy üzerinden yönlendirilen IP adresim nedir aracını kullanın.

Protokoller: HTTP, HTTPS ve SOCKS5

Yukarıdaki fiziksel zincir, Nodetonet'in desteklediği üç protokolü de taşır. Fark, hop 3'te socks5Server'ın ne yaptığındadır:

• HTTP CONNECT — istemci bir CONNECT tünel isteği gönderir; sunucu hedef host'a TCP röle kurar.
• HTTPS — proxy için HTTP CONNECT ile özdeştir ancak istemciden gelen TLS Cloudflare edge'inde sonlanır ve cihazdan hedefe olan iç TLS uçtan uca şifreli kalır.
• SOCKS5 — istemci SOCKS5 el sıkışmasını (isteğe bağlı kullanıcı adı/şifre auth ile) müzakere eder, ardından sunucu istenen hedefe TCP bağlantısı açar. SOCKS5 yalnızca HTTP değil herhangi bir TCP trafiğini destekler — veritabanı istemcileri, oyun botları, özel ikili protokoller ve daha fazlası için çalışır. Bkz. kimlik doğrulamalı SOCKS5.

Edge-panel ayrımı ve neden önemlidir

Nodetonet, birçok tek-sunucu proxy sisteminin birlikte çalıştırdığı iki katmanı ayırır: kontrol düzlemi (panel — faturalandırma, yapılandırma, gösterge paneli) ve veri düzlemi (edge sunucu — gerçek proxy trafiği). Edge sunucu yapılandırmayı panelden çeker ve ardından özerk olarak çalışır. Bu ayrım, edge'in yüksek eş zamanlılığı panel bir darboğaza dönüşmeden işleyebilmesini ve bir panel yeniden başlatmasının etkin tünelleri kesmemesini sağlar.

Aynı zamanda birden fazla edge sunucuyu farklı bölgelerde çalıştırabileceğiniz ve farklı proxy'leri her birine atayabileceğiniz anlamına gelir — tek parça bir kurulumla imkansız olan bir mimari. Kendi edge düğümünüzü çalıştırmaya veya tam platformu kurmaya ilgi duyuyorsanız ana rehberden başlayın ya da özellikler genel bakışını inceleyin.

Sırada okunacaklar

• Doğru edge sunucusunu seçmek — iş yükünüz için hangi PoP'u seçeceğiniz.
• Tünel sağlığını izlemek — yukarıdaki zinciri nasıl takip edeceğiniz.
• Sticky oturumlar açıklandı — bir oturumu istekler boyunca bir cihaza sabitleme.
• Mobil proxy'ler için otomatik yük devretme — oturum ortasında bir cihaz düştüğünde ne olur.
• Ücretsiz hesap oluşturun — tam veri yolunu dakikalar içinde gerçekte görün.