AI relay hizmetlerinde hesap kapatmaları etkili biçimde nasıl azaltılır

Wokey Team · 2026-06-27

Model sağlayıcıları yakın zamanda büyük bir hesap kapatma dalgası gerçekleştirdi — öyle genişti ki meşru kullanımı olan bireysel kullanıcılar bile arada kaldı.

Bir relay hizmeti işletiyorsanız veya bir tane seçiyorsanız bunun üzerine ciddi biçimde düşünmeye değer: hesap kapatmalar şans meselesi mi, yoksa mimari meselesi mi?

Benim cevabım ikincisi. Kapatılma oranları rastgele değildir — onları mimari belirler.

Biraz geriden bakalım. Sağlayıcılar bir hesabın paylaşıldığına veya yeniden satıldığına karar verirken genellikle şu sinyallere bakar:

• IP değişiklikleri ve IP türü — istekleriniz bir anda konut IP'sinden veri merkezi IP'sine sıçrar veya farklı coğrafi konumlar arasında gezinir.
• Davranış anormallikleri — tek bir kişiye açıkça benzemeyen çağrı sıklığı, eşzamanlılık ve zaman dağılımı.
• Aynı çıkışı paylaşan birden fazla hesap — onlarca hesabın isteklerinin aynı IP grubundan akması.
• İstemci parmak izi anormallikleri — normal bir istemciyle eşleşmeyen istek başlıkları, TLS parmak izi ve cihaz özellikleri.

Bu sinyalleri üst üste koyun; sağlayıcının risk sistemi hesabınızı işaretler.

Ama hangi sinyalin en ağır bastığını ve en kolay tespit edildiğini sorarsanız — bence bu IP'dir.

Nedeni basit: IP en dıştaki, en düşük maliyetli eleme ölçütüdür. Konut IP'sinden gelen bir istek ile veri merkezi IP'sinden gelen bir istek, risk sisteminin gözünde bambaşka risk kademelerindedir. Veri merkezi ASN'i + IP sıçraması + coğrafi anormallik — bu üçü birlikte göründüğünde risk sistemine neredeyse "bu normal bir kullanıcı değil" demiş olursunuz.

Açıkçası, geleneksel relay hizmetlerinin mimarisi tam da bu mayına basar: tüm istekler relay'in sunucularından çıkar ve onlarca hesap aynı veri merkezi IP grubunu paylaşır. Yükü nasıl dengelerseniz dengeleyin, proxy havuzunuzu nasıl döndürürseniz döndürün, çıkış noktası özünde bir sunucu odasıdır. Başka relay işletmecilerinin çözümlerine baktım — proxy'leri özenle döndürüyorlar, ama hızlı bir ASN sorgusu hepsinin bulut sağlayıcısı olduğunu gösteriyor. Maske farklı, yüz aynı.

Bu yüzden bazıları üç relay hizmeti arasında geçiş yapıp her birinde iki haftada bir kapatılır — bu şanssızlık değildir; her hizmetin mimarisi aynıdır.

Peki IP nasıl sabit tutulur?

Bireysel bir kullanıcıysanız zaten yerleşik bir yaklaşım var: evdeki bir NAS'a New API veya One API gibi birleşik bir gateway kurun ya da sam-to-API gibi araçlar kullanın ve tüm sağlayıcı API'lerini onun üzerinden yönlendirin. Telefonunuz, dizüstü bilgisayarınız, model çağıran herhangi bir istemci — hiçbiri sağlayıcıya doğrudan gitmez. Bunun yerine evinizdeki cihazdan geçer; o da isteği sağlayıcı API'sine iletir. Böylece hangi modeli çağırırsanız çağırın, sağlayıcının gözünden çıkış IP'si her zaman evinizin internet IP'sidir — evde oturup normal şekilde kullanmanızdan ayırt edilemez.

Dışarıdayken ne olacak? Telefonunuzun veya dizüstü bilgisayarınızın trafiğini önce evdeki NAS'a, oradan da dışarıya yönlendirmek için Tailscale veya WireGuard gibi mesh ağ araçlarını kullanın. İster bir kafede, ister ofiste, ister trende olun, istekleriniz yine evinizin internetinden çıkar. Sağlayıcı, Wi-Fi değiştirdiniz veya mobil veriyi açtınız diye IP'nizin sıçradığını hiç görmez.

Bu yaklaşım fnOS topluluğunda ve kendi sunucusunda AI barındıranlar arasında kendini kanıtlamıştır; bol miktarda rehber ve uygulayıcı vardır. Bireysel kullanıcılar için şu anda en güvenilir IP sabitleme çözümü budur.

Ama bu yalnızca tek bir kişinin sorununu çözer.

Bir relay hizmeti onlarca veya yüzlerce Provider'ın hesaplarını yönetir. Her birinin evine gidip NAS kuramaz, gateway yapılandıramazsınız. Her Provider'ın hafif bir node kurup platforma bağlanmasını sağlayan sistematik bir çözüme ihtiyacınız vardır — istekler yine Provider'ın kendi ağından çıkar, ama sipariş dağıtımı ve trafik yönlendirme merkezi olarak platform tarafından yürütülür.

Bu mimariye provider-side exit denir — istekler relay'in sunucularından değil, Provider'ın kendi ağından çıkar.

Bir benzetme: NAS yaklaşımı yol kenarında kendi dükkânınızı işletmeye benzer — evden gönderim yaparsınız; tedariki, seçimi ve siparişleri tek başınıza halledersiniz. Provider Node ise bir platformun bayilik ağına katılmaya benzer — yine evden gönderim yaparsınız, ama siparişleri size platform dağıtır. Gönderim adresi değişmez; değişen, siparişleri kimin dağıttığıdır.

Wokey Provider Node'un yaptığı budur.

Kurulum basittir — tek bir komut; macOS, Linux, Windows ve Docker desteklenir. Kurulumdan sonra yerel konsolu açın, Wokey hesabınızı bağlayın ve yerel abonelik kimlik bilgilerinizi içe aktarın. Node başladığında Wokey platformuyla bir WebSocket bağlantısı sürdürür. Platform kullanıcı isteklerini gönderir, node da isteği vendor API'sine yerelde başlatır. Tüm süreç Provider'ın kendi IP'sinden çıkar — vendor için bu, Provider'ın kendi aboneliğini normal şekilde kullanmasıyla aynıdır.

Şu anda desteklenen vendor'lar arasında OpenAI/Codex, Anthropic/Claude, Zhipu, Kimi, DeepSeek, Gemini, xAI ve başkaları bulunur.

Bu mimariyi kendim çalıştırdıktan sonra en sezgisel çıkarım şu: risk kontrolleriyle "savaşmıyor" — risk tespitinin ön koşullarını hiç tetiklemiyor. Vendor'ın gözünden bu, evinde kendi aboneliğini kullanan normal bir kullanıcıdır; açıklanması gereken hiçbir anormallik yoktur.

Projenin tamamı Apache-2.0 lisansıyla açık kaynaktır ve çıkış beyaz listesi kaynak koda sabit olarak yazılmıştır. Ben öyle dediğim için güvenli değildir — her kod satırı denetlenebildiği için güvenlidir.

Elbette provider-side exit'in sıfır kapatma garantisi verdiğini iddia etmeyeceğim. IP yalnızca kapatılma etkenlerinden biridir — çağrı sıklığı, eşzamanlılık örüntüleri ve zaman dağılımı da risk kontrollerini tetikleyebilir. Hiçbir çözüm sıfır kapatılma oranını garanti edemez.

Ama mantık açık: en büyük sinyali ele almadıysanız diğer her iyileştirme kum üzerine kurulur.

Kapatılma oranlarını düşürmenin anahtarı, kullanımınızı normal kullanımdan ayırt edilemez kılmaktır. IP'yi sabit tutmak en kritik parçadır. Bireysel kullanıcıların bireysel çözümleri vardır; relay hizmetlerinin ise sistematik bir provider-side exit yaklaşımına ihtiyacı vardır.

Relay rekabeti son aşamasına vardığında mesele kimin daha çok modeli veya daha düşük fiyatı olduğu olmayacak — kimin mimarisinin sağlayıcıya relay olduğunuzu fark ettirmediği olacak. Şu anda kullandığınız hizmet — istekler kimin ağından çıkıyor?