Proxy Neden Webhook Kabul Etmez: Bağlantı Yönü ve Bunun Yerine Ne Kullanmalı

Giriş: «proxy alayım, webhook bana gelir» beklentisi neden gerçekleşmez

Proxy hizmetlerinin teknik desteğine sürekli aynı soru farklı cümlelerle geliyor. «Mobil proxy aldım, adresini entegrasyon ayarlarına girdim, ama ödeme sağlayıcısı bildirim göndermiyor.» «CRM'de webhook URL'si olarak proxy'nin IP'sini girdim, bağlantı hatası veriyor.» «Betiğim proxy üzerinden her şeyi görüyor, ama aynı proxy üzerinden beni kimse görmüyor, neden?» Cümleler farklı, kök neden aynı: proxy'nin ne yaptığına dair yanlış bir zihinsel model.

Beklenti anlaşılır. Proxy size «başka bir IP adresi» veriyor ve bu adres genel, tüm IP kontrol servisleri bunu gösteriyor. Mantık şunu fısıldıyor: genel bir adresim varsa, o adresten bana ulaşılabilir. Ama durum böyle değil. Proxy, Proxeon mobil proxy dahil, giden istekler sorununu çözer: kodunuz bağlantı başlatır, bağlantı proxy düğümünden geçer ve uzak sunucu bu düğümün adresini görür. Ters görev, yani uzak sunucunun size bağlantı başlatması, proxy tarafından hiç çözülmez. Tarifede bir şey eksik olduğu için değil, bu görev temelden farklı kurgulandığı için.

Bu yazıda konuyu köküne kadar ele alacağız. Giden bağlantının gelen bağlantıdan TCP düzeyinde nasıl farklılaştığını, proxy istemcisinin neden dinleyen port açmadığını ve size dışarıdan erişilebilir bir adres vermediğini, mobil ağdaki abone adresinin doğası gereği dışarıdan adreslenemez olduğunu ve en önemlisi webhook kabul etmek için gerçekte ne kullanılması gerektiğini öğreneceksiniz: genel adresli sunucu, ters tünel, sağlayıcı tarafında olay kuyruğu veya iyi tasarlanmış bir anket. Ayrıca proxy'nin bu şemada hâlâ yerinde olduğu noktayı da göreceğiz, çünkü gerçekten bir yeri var. Port yönlendirme ve ev yönlendiricisi yapılandırması kapsam dışında kalıyor: bu komşu bir konu, biz sadece uygulanabilirliğinin sınırını çizeceğiz.

Yazı, üçüncü taraf API'ler üzerine otomasyon kuran entegrasyon geliştiricileri, DevOps mühendisleri ve teknik uzmanlar için yazıldı. Kod örnekleri Python ile ve kabuk komutları biçiminde verildi; temel olarak alınabilir.

Temeller: bağlantı yönü, yani kim kime kapıyı çalıyor

Devam etmek için anlamsız olan temelden başlayalım. TCP/IP ağlarında her bağlantının bir başlatanı ve bir dinleyicisi vardır. Başlatan, SYN bayraklı ilk paketi gönderir. Dinleyici önceden bir port açmış, orada bekliyor ve SYN-ACK ile yanıtlıyor. Ancak bu el sıkışmadan sonra veri iki yöne akar. Buradaki kilit kelime «önceden»: dinleyici, başlatanın kapıyı çalmak isteyeceği anda zaten internetten yönlendirilebilen bir adreste bulunmalı ve portu açık tutuyor olmalı.

Proxy üzerinden giden istek şeması

Şemayı metinle canlandıralım. Betiğiniz evde veya ofiste NAT arkasında, ya da mobil modemli bir dizüstünde çalışıyor.

• Adım 1. Betiğiniz proxy düğümüne bağlantı başlatır: [kodunuz] → [Proxeon düğümü].
• Adım 2. Proxy düğümü kendi adına hedef siteye bağlantı başlatır: [Proxeon düğümü] → [api.example.com].
• Adım 3. Hedef site, zaten açık olan bağlantı üzerinden ters yönde yanıt verir, proxy düğümü yanıtı sizin açtığınız bağlantı üzerinden size iletir.

Dikkat edin: sunucunun yanıtı gelen bir bağlantı değildir. Bu, sizin açtığınız kanaldan geri gelen veridir. Kapıyı siz açtınız, alışveriş sürdüğü sürece onu siz tutuyorsunuz. Bağlantıyı kapattığınız anda geri dönüş yolu yoktur. Dışarıdan kimse kendi inisiyatifiyle «konuşmayı sürdüremez».

Webhook şeması

Şimdi webhook. Ödeme sağlayıcısı, mesajlaşma uygulaması, CRM veya pazaryeri size bir olayı bildirmek ister: ödeme geçti, mesaj geldi, sipariş durumu değişti.

• Adım 1. Sağlayıcı, abone olurken verdiğiniz URL'yi alır, alan adını IP adresine çözer.
• Adım 2. Sağlayıcı bu adrese 443 portundan bağlantı başlatır: [sağlayıcı sunucusu] → [sizin URL'niz].
• Adım 3. Bu adres ve portta birinin dinliyor olması, geçerli sertifikayla TLS el sıkışmasını kabul etmesi, HTTP isteğini çözümlemesi ve 2xx koduyla yanıt vermesi gerekir.

Burada başlatan sağlayıcıdır. Dinleyici siz olmalısınız. Ve tüm yazının ayrıntılı yanıt verdiği soru tam burada: sağlayıcıya hangi adresi vereceksiniz? Proxy adresini mi? Ama proxy düğümü sizin için dinlemiyor. Ev bağlantınızın adresini mi? Ama o ya özel ya da operatörün NAT'ı arkasında. Modemli dizüstü mü? Onun yönlendirilebilir adresi bile yok.

Her şeyi yerine oturtan bir benzetme

Proxy, giden mektuplar için bir kurye hizmetine benzer. Mektubu kuryeye verirsiniz, o alıcıya götürür ve zarfın üzerinde sizin ev adresiniz değil, kurye şirketinin adresi yazar. Alıcı yanıtı aynı zarfa koyabilir, kurye geri döner ve size verir, çünkü mektubu kimden aldığını hatırlıyor. Ama alıcı bir hafta sonra size kendisi yazmak isterse, şirketin adresine yazar. Şirket mektubu alır ve binlerce müşteriden hangisine hitaben yazıldığını bilemez. Muhtemelen mektup şirketin posta kutusuna bile ulaşmaz, çünkü orada gelen kutusu yoktur. Mektup almak için giden posta hizmeti değil, kendi posta adresiniz gerekir.

Derinlemesine bakış: proxy istemcisi neden port dinlemez ve genel adres vermez

Protokol düzeyine inelim. İki yaygın proxy ailesi vardır: HTTP proxy ve SOCKS proxy. Her birinin neler yapabildiğine bakalım ve gelen bağlantıların hizmetinize yönlendirilmesinin ne kâğıt üzerinde ne de pratikte bu listeye dahil olmadığını doğrulayalım.

HTTP proxy nasıl çalışır

HTTP proxy istemciden GET http://host/path biçiminde bir istek ya da HTTPS için CONNECT host:443 komutunu alır. İkinci durumda proxy hedef konağa TCP bağlantısı açar ve sonrasında şifreli trafiğin içine bakmadan sadece iki yönde bayt taşır. O kadar. Protokolde «benim için bir port dinlemeye başla» veya «bana bir adres kaydet» komutu yoktur. İstemci her zaman başlatandır, proxy her zaman «istemciden dünyaya» yönünde aracıdır.

Python'da proxy üzerinden giden isteğin asgari örneği şöyle. Çalışır, çünkü yön doğrudur:

import requests

PROXY = 'http://user:pass@gate.proxeon.net:PORT'
proxies = {'http': PROXY, 'https': PROXY}

r = requests.get('https://api.example.com/v1/status', proxies=proxies, timeout=(5, 30))
print(r.status_code, r.json())

Peki ya başarısızlığa mahkûm girişim? Diyelim ki proxy'nin dış IP'sini, örneğin bir adres kontrol servisi üzerinden öğrendiniz ve bunu webhook URL'si olarak girmeye karar verdiniz:

curl -v --max-time 10 http://203.0.113.45/webhook
# sonuç: connect() timed out veya Connection refused

Neden? 203.0.113.45 adresinde, istemcilerden komut almak için hizmet portunu dinleyen proxy yazılımı çalışıyor, sizin /webhook yolunuzu değil. 80 portunda bir şey yanıtlasa bile bu sizin kodunuz olmazdı. Sizin kodunuz başka bir makinede, başka bir adreste ve proxy sunucusunun /webhook yoluna gelen isteğin tam olarak size iletilmesi gerektiğinden, aynı çıkış adresini kullanan yüzlerce diğer istemciden birine değil, hiç haberi yok.

Peki ya SOCKS5 ve BIND komutu?

Burada çok az kişinin bildiği en ilginç kısım başlıyor. SOCKS5 belirtiminde gerçekten üç komut tanımlanır: CONNECT, BIND ve UDP ASSOCIATE. BIND komutu tam da ters senaryo için düşünülmüştü: istemci proxy'den bir dinleme portu açmasını, ardından tek bir gelen bağlantıyı kabul edip istemciye iletmesini ister. Bu, FTP'nin aktif modundan miras kalmıştır; orada sunucunun veri aktarımı için istemciye bağlanması gerekir.

Sanki çözüm bulundu. Ancak BIND'in pratikte size yardımcı olmayacağının üç nedeni var:

1. BIND tam olarak tek bir gelen bağlantıyı kabul eder ve ancak siz aynı konağa zaten giden bir bağlantı kurduktan sonra. Bu «herkes için sürekli port dinlemek» değil, «zaten konuştuğum tek bir muhatap için kapı açmak» demektir.
2. Ticari proxy sunucularının büyük çoğunluğu BIND komutunu ya uygulamaz ya da güvenlik gerekçesiyle kapatır. Yüzlerce istemciye hizmet veren ortak bir düğümde açık dinleme portu saldırı vektörü ve suistimal kaynağıdır, bu yüzden yoktur.
3. BIND'in olduğu yerlerde bile adres ve port dinamik olarak, kısa süreliğine tahsis edilir ve TLS sertifikalı bir webhook URL'si olarak kaydedilmeye hiç uygun değildir.

Özetle: belirtimde kuramsal bir olasılık var, ama webhook kabul etmek için pratik bir fayda sağlamaz.

Proxy ile birlikte ne elde edersiniz, ne etmezsiniz

Son derece net biçimde ifade edelim. Proxy satın alarak şunları elde edersiniz:

• giden isteklerinizde uzak sunucuların gördüğü çıkış IP adresini;
• bu adresin coğrafi ve ağ aidiyetini, örneğin belirli bir bölgedeki mobil operatörün havuzundan bir adres;
• bu adresi döndürme ya da tam tersine oturum süresince sabit tutma imkânını;
• birden fazla bağımsız entegrasyon yürütüyorsanız, giden trafiği farklı kanallara ayırma imkânını.

Şunları elde etmezsiniz:

• çıkış adresinde dinleyen bir port;
• üçüncü tarafların bağlantı başlatabileceği yönlendirilebilir bir adres;
• hizmetinize bağlı bir alan adı ve TLS sertifikası;
• tarife döndürmeyi öngörüyorsa çıkış adresinin bir saat sonra da aynı olacağı garantisi.

Bu tablo kafaya oturduğu anda «webhook neden proxy'ye gelmiyor» sorusu soru olmaktan çıkar. Apaçık bir gerçeğe dönüşür.

Mobil ağlar ve ortak adres: abone adresi neden dışarıdan adreslenemez

Mobil ağlar ayrı bir tartışmayı hak ediyor, çünkü «webhook gelmiyor» hikâyelerinin başrolünde çoğunlukla mobil proxy'ler var. Burada proxy'nin kendi kısıtlarına operatör ağının mimarisi de eklenir ve etkiyi kat kat artırır.

Adres kıtlığı ve CGNAT

Dünyada yaklaşık dört milyar genel IPv4 adresi var, aktif mobil bağlantı sayısı ise belirgin biçimde daha fazla. Hiçbir operatör her aboneye kendi genel adresini veremez. Bu yüzden operatörler Carrier-Grade NAT kullanır (CGNAT, operatör düzeyinde adres dönüşümü). Abone cihazı, özel olarak ayrılmış 100.64.0.0/10 aralığından ya da bilinen 10.0.0.0/8 aralığından özel bir adres alır, ağ sınırında ise binlerce abone adresini bir veya birkaç genel adrese dönüştüren güçlü bir NAT ağ geçidi durur.

Adreslenebilirlik açısından nasıl görünüyor? Modeminiz dışarı paket gönderdiğinde ağ geçidi tabloya şunu yazar: «abone 100.72.14.9, port 51234 → genel adres 203.0.113.45, port 40001». 203.0.113.45:40001'e gelen yanıtı ağ geçidi kayıtla eşleştirir ve size döndürür. Ancak kayıtlar yalnızca giden trafikle oluşturulur ve hareketsizlik halinde saniyeler veya dakikalar içinde yaşar. Dışarıdan biri 203.0.113.45'e 443 portundan paket gönderirse, tabloda bu paketle eşleşen hiçbir kayıt olmaz. Ağ geçidi onu düşürür. «Engellemek» değil, bin aboneden hangisine hitaben yazıldığını anlayamaz.

Bu neden abone tarafında giderilemez

Ev sağlayıcısıyla bazen durum farklıdır: bazı tarifeler yönlendiriciye gerçek genel adres verir, o zaman komşu bir konu ortaya çıkar — port yönlendirme ve yönlendirici yapılandırması. Bunu bilinçli olarak ele almıyoruz, sadece uygulanabilirlik sınırını tespit edelim: port yönlendirme yalnızca ekipmanınızda gerçek yönlendirilebilir adres varsa anlamlıdır. Mobil ağda abonenin böyle bir adresi prensipte yoktur, yönlendirilecek bir şey ve yer yoktur, ekipman yapılandırması bu gerçeği etkilemez. Çoğu operatörde mobil abone için genel adres seçeneği ya yoktur ya da ayrı bir kurumsal hizmet olarak sunulur, bunun artık proxy ile ilgisi yoktur.

Ek katmanlar: döndürme ve filtreleme

CGNAT'e iki etken daha ekleniyor. Birincisi, abonenin çıktığı genel adres periyodik olarak değişir: yeniden bağlanmada, yük dengelemede, baz istasyonu değişiminde. Proxeon mobil proxy'leri tam da bu özelliği yararlı biçimde kullanır: adres zamanlamayla veya talep üzerine döndürülebilir. Ancak webhook kabulü için adres kararlılığı kritiktir ve burada tanımı gereği yoktur. İkincisi, operatörler ağ sınırında gelen trafiğin bir kısmını filtreler, çünkü abone cihazları sunucu olmaya uygun değildir. Abonenin genel bir IPv6 adresi aldığı yerlerde bile gelen bağlantılar çoğu zaman operatörün güvenlik duvarıyla kapatılmıştır.

Bu bölümün sonucunu vurgulamak gerekir: mobil proxy adresi bir çıkış kimliğidir, hizmet adresi değildir. Bu ürünün eksikliği değil, doğasıdır. Mobil proxy, giden isteklerin belirli bir operatörün ve bölgenin normal abonesinin trafiği gibi görünmesi için alınır. Bu trafik abone trafiğinden ayırt edilemediği için aboneye özgü dışarıdan adreslenememe özelliğini de miras almıştır.

Webhook kabul sorununu gerçekten çözen dört çalışan yaklaşım

Teşhisten tedaviye geçelim. Kodunuz NAT arkasında, mobil modemde ya da dizüstünde yaşadığında dış sistemlerden olay kabul etmenin dört olgun yolu var. Her birinin kendi nişi, kendi maliyeti ve kendi kısıtları var. Sırayla örneklerle ele alalım.

Yaklaşım 1. Genel adresli sunucu

En doğrudan ve en güvenilir yol. Bir barındırma sağlayıcısından sanal sunucu kiralarsınız, beraberinde genel IPv4 adresi alırsınız, ona bir alan adı bağlarsınız, TLS sertifikası çıkarırsınız ve alıcıyı çalıştırırsınız. 2026'da webhook sağlayıcıları neredeyse istisnasız geçerli sertifikalı HTTPS gerektirir, bu yüzden bu adım zorunludur.

Adım adım plan:

1. Veri saklama gereksinimlerinize uygun yargı yetkisinde minimum yapılandırmalı bir VPS kiralayın.
2. hooks.yourdomain.tld biçiminde bir alan adı için sunucunun adresini gösteren bir A kaydı oluşturun.
3. Web düzeyinde ters proxy (nginx veya eşdeğeri) kurun ve ACME istemcisi üzerinden sertifika çıkarın.
4. Alıcı uygulamayı dünyaya kapalı yerel bir portta çalıştırın, web sunucusunu ona yönlendirin.
5. Sağlayıcıya hızlı yanıt vermek için imza doğrulama ve işleme kuyruğu ayarlayın.

HMAC imzası doğrulayan ve hızlı yanıt veren Flask tabanlı alıcı örneği. Ağır işlemeyi kuyruğa bırakıyoruz, çünkü çoğu sağlayıcı 5–10 saniyeden fazla beklemez:

import hmac, hashlib, json, os
from flask import Flask, request, abort
from queue import Queue

app = Flask(__name__)
SECRET = os.environ['WEBHOOK_SECRET'].encode()
jobs = Queue()

def valid_signature(raw_body, header_sig):
expected = hmac.new(SECRET, raw_body, hashlib.sha256).hexdigest()
return hmac.compare_digest(expected, header_sig or '')

@app.post('/webhook/payments')
def payments():
raw = request.get_data()
if not valid_signature(raw, request.headers.get('X-Signature')):
abort(401)
event = json.loads(raw)
jobs.put(event) # arka planda işleme, hemen yanıt
return '', 200

Üç ayrıntıya dikkat edin. İmza, ayrıştırılmış JSON üzerinden değil ham istek gövdesi üzerinden doğrulanır, aksi halde herhangi bir yeniden biçimlendirme karşılaştırmayı bozar. Karşılaştırma compare_digest ile yapılır, zamanlama sızıntısını önlemek için. 200 yanıtı işlemeden önce verilir, olay kendisi kuyruğa gider. Sağlayıcı ayrılan sürede 2xx almazsa teslimatı başarısız sayar ve tekrarlamaya başlar, siz kopyalar alırsınız.

Yaklaşım 2. Ters tünel

Kod tam da yerel makinenizde, sunucuda değil, çalışacaksa ters tünel kullanın. Fikir zarif ve yukarıda tartıştığımız her şeyle tamamen uyumlu: makineniz kendisi genel bir sunucuya giden bağlantı başlatır, o da sizin adınıza port dinlemeye başlar ve gelen istekleri zaten açık kanala yönlendirir. Başlatma yönü gidendir, dolayısıyla NAT ve CGNAT ona engel olmaz. Genel dinleyici sunucudadır, dolayısıyla webhook sağlayıcısı ona ulaşabilir.

SSH ile en basit uygulama. Genel sunucuda sshd yapılandırmasında GatewayPorts seçeneği açık olmalı ya da ön uç olarak yerel bir web sunucusu kullanılmalı. Yerel makineden:

# yerel alıcı 127.0.0.1:8080'i dinliyor
# sunucudan 127.0.0.1:9000'i dinlemesini ve trafiği bize yönlendirmesini istiyoruz
ssh -N -R 9000:127.0.0.1:8080 tunnel@hooks.yourdomain.tld

# sunucuda nginx https://hooks.yourdomain.tld/webhook -> 127.0.0.1:9000 yönlendirir

Endüstriyel kullanım için tek bir ssh süreci yeterince güvenilir değildir: bağlantı kopabilir. Otomatik yeniden bağlanan bir sarmalayıcı (autossh veya benzeri bir gözetleyici) kullanın ve kopmaların saniyeler içinde fark edilmesi için ServerAliveInterval açın. Aynı ilke üzerine kurulu özel tünel hizmetleri ve kendi barındırdığınız çözümler de mevcut, otomatik sertifika çıkarma ve web paneliyle. İlke her yerde aynı: yerel ajan giden bağlantıyı tutar, genel taraf webhook'ları kabul eder.

Yaklaşımın kısıtlarını akılda tutmak gerekir. Tünel koptuğu sürece webhook'lar kaybolur ya da sağlayıcının tekrarlarına düşer. Bazı tünel hizmetlerinin geçici adresleri yeniden başlatmada değişir, bu üretim için kabul edilemez: sabitlenmiş alan adı gerekir. Ve tünel gecikme ile bir hata noktası ekler. Geliştirme ve hata ayıklama için mükemmel bir araçtır, işletim için yalnızca izleme ile birlikte uygundur.

Yaklaşım 3. Sağlayıcı tarafında olay kuyruğu

Birçok olgun API, push modeline alternatif sunar: olaylar sağlayıcı tarafında bir günlüğe veya kuyruğa yazılır, siz uygun olduğunuzda alırsınız. Bu, bağlantı yönünü sizin için giden yapar ve tüm adreslenebilirlik sorunu ortadan kalkar.

Kanonik örnek, bir mesajlaşma uygulamasının getUpdates metoduyla Bot API'si: sunucu okunmamış güncellemeleri bir güne kadar saklar, istemci periyodik olarak son işlenen ofseti ileterek alır. Benzer mekanizmalar ödeme sistemlerinde imleçli olay listesi biçiminde, pazaryerlerinde sipariş değişiklik kuyruğu biçiminde, bulut sağlayıcılarında webhook'ların yönlendirilebileceği ve istemcinin okuduğu yönetilen mesaj kuyrukları biçiminde mevcuttur.

import requests, time

TOKEN = 'your-bot-token'
BASE = f'https://api.messenger.example/bot{TOKEN}'
offset = 0

while True:
resp = requests.get(f'{BASE}/getUpdates',
params={'offset': offset, 'timeout': 50},
timeout=60)
for upd in resp.json().get('result', []):
handle(upd)
offset = upd['update_id'] + 1

Burada timeout=50 parametresi long polling'i açar: sunucu bir olay gelene kadar veya zaman aşımı dolana kadar bağlantıyı açık tutar, siz de sık boş istekler olmadan neredeyse anında teslimat alırsınız. Bu giden bir bağlantıdır, NAT üzerinden, mobil modem üzerinden ve gerekirse proxy üzerinden sorunsuz çalışır.

Sağlayıcı entegre bir kuyruk sunmuyorsa, birinci yaklaşımdan kendiniz kurabilirsiniz: VPS'teki asgari alıcı webhook'ları kabul eder ve bir mesaj kuyruğuna koyar, yerel makineniz kuyruğu okur. Genel adresin güvenilirliğini yerel yürütmenin esnekliğiyle birleştiren bir melez elde edilir.

Yaklaşım 4. Abonelik yerine anket

Sağlayıcıda ne webhook ne olay kuyruğu varsa, klasik durum anketi kalır: kaynağı periyodik olarak sorgular ve önceki durumla karşılaştırırsınız. Bu en evrensel yaklaşımdır, çünkü sağlayıcıdan normal okuma API'sinden başka bir şey gerektirmez. Ancak aynı zamanda tasarıma en çok özen isteyen yaklaşımdır: sabit aralıklı saf döngü hızla istek limitlerine takılır, boş yanıtlara bütçe harcar ve yine de olaylarda geç kalır. Bir sonraki bölüm tamamen bunu önlemeye ayrıldı.

İşinize yarayacak araçlar

• Ön uç web sunucusu (nginx veya eşdeğeri), TLS sonlandırma ve uygulamaya yönlendirme için.
• ACME istemcisi, sertifikaların otomatik çıkarılması ve yenilenmesi için.
• Mesaj kuyruğu (Redis Streams, RabbitMQ veya bulutun yönetilen kuyruğu), olayları kabul ve işleme arasında tamponlamak için.
• Tünel gözetleyicisi, ters tüneller için otomatik yeniden bağlanmayla.
• Yerel istek denetleyicisi hata ayıklama için: başlıkları ve gövdeyi kaydeden herhangi bir asgari HTTP sunucusu, sağlayıcının tam olarak ne gönderdiğini görmenize yardımcı olur.
• Proxeon proxy, işleyicilerden üçüncü taraf API'lere giden çağrılar için, konuyu aşağıda ayrıntılı ele alıyoruz.

Webhook yerine anket: limitlere takılmamak için nasıl tasarlanmalı

Anket savurganlıkla eleştirilir ve çoğu zaman haklı olarak. Ama savurgan olan anketin kendisi değil, kötü uygulanmasıdır. Doğru tasarlanmış bir anketleyici API üzerindeki yük açısından webhook'larla kıyaslanabilir ve hatta daha güvenilirdir, çünkü gelen bağlantıların ulaştırılabilirliğine bağlı değildir. İlkeleri ele alalım.

İlke 1. Tam seçim yerine imleç

Asla «tüm siparişleri» istemeyin ve değişiklikleri kendi tarafınızda aramayın. Neredeyse her modern API'de bulunan since, updated_after, cursor veya page_token gibi parametreleri kullanın. Son imleci kalıcı olarak saklayın, böylece süreç yeniden başlatıldığında geçmişin yeniden çekilmesi olmaz. İmleçle gelen yanıt küçüktür, hızlı işlenir ve sağlayıcıya yük bindirmez.

İlke 2. Koşullu istekler

Kaynak ETag ve If-None-Match ya da Last-Modified ve If-Modified-Since başlıklarını destekliyorsa kullanın. 304 Not Modified yanıtı gövde içermez ve çoğu zaman limite sayılmaz ya da indirimli sayılır. Trafiği kat kat azaltmanın bedava yolu.

İlke 3. Jitter'lı uyarlanabilir aralık

Sabit aralık iki kez kötüdür: sessiz saatlerde istekleri boşa harcar, yoğun saatlerde geç kalır. Uyarlanabilir şema basit: boş yanıttan sonra aralığı artırın (örneğin 1,5 ile çarpıp tavana kadar), dolu yanıttan sonra minimuma sıfırlayın. Birkaç örneğinizin API'ye eşzamanlı vurmaması için yüzde 10–20 rastgele sapma ekleyin.

İlke 4. Sunucu sinyallerine saygı

Retry-After, X-RateLimit-Remaining ve X-RateLimit-Reset başlıkları süs olsun diye yok. 429 aldığınızda tam söylenen kadar bekleyin. Kalan limitin eşiğin altına düştüğünü görünce önceden yavaşlayın. Bu sadece nezaket değil, anahtarın geçici bloklanmasına karşı da korumadır.

İlke 5. İşlemenin idempotentliği

Anket doğası gereği aynı olayı iki kez döndürebilir: imleç sınırında, arıza sonrası, pencereler çakıştığında. Her olayın benzersiz bir tanımlayıcısı olmalı, işleyicinin de makul saklama süreli, işlenmiş tanımlayıcı tablosu. Aynı kural webhook'ların tekrar teslimatlarındaki kopyalardan da korur.

Hazır uyarlanabilir anketleyici iskeleti

import random, time, requests

MIN_INTERVAL, MAX_INTERVAL = 5, 300
interval = MIN_INTERVAL
cursor = load_cursor() # veritabanından veya dosyadan
etag = None
seen = SeenStore(ttl_hours=48) # işlenmiş id deposu

while True:
headers = {'If-None-Match': etag} if etag else {}
r = requests.get('https://api.example.com/v1/events',
 params={'cursor': cursor, 'limit': 100},
 headers=headers, timeout=(5, 30))

if r.status_code == 429:
time.sleep(int(r.headers.get('Retry-After', 60)))
continue
if r.status_code == 304:
interval = min(interval * 1.5, MAX_INTERVAL)
elif r.ok:
etag = r.headers.get('ETag')
events = r.json()['data']
for ev in events:
if not seen.contains(ev['id']):
handle(ev)
seen.add(ev['id'])
if events:
cursor = r.json()['next_cursor']
save_cursor(cursor)
interval = MIN_INTERVAL
else:
interval = min(interval * 1.5, MAX_INTERVAL)

remaining = int(r.headers.get('X-RateLimit-Remaining', 1000))
if remaining < 50:
interval = max(interval, 60)

time.sleep(interval * random.uniform(0.9, 1.2))

Anket tasarımı kontrol listesi

• İmleç veya zaman damgası kalıcı olarak saklanır ve yeniden başlatmayı atlatır.
• API destekliyorsa koşullu istekler kullanılır.
• Aralık uyarlanabilir, tavanlı ve jitter'lı.
• 429 kodu ve Retry-After başlığı açıkça işlenir.
• Her olay benzersiz tanımlayıcıyla idempotent işlenir.
• Bağlantı ve okuma zaman aşımları açıkça ve ayrı ayrı tanımlanır.
• Metrikler: istek sıklığı, boş yanıt oranı, olaydan işlemeye gecikme.
• Sağlayıcı long polling destekliyorsa açılır, normal anket kapatılır.

Bu tasarımla minimum 5 saniye aralıklı bir anketleyici sessizlikte 5 dakika aralığa çıkar ve kaynak başına günde yaklaşık 300 istek yapar. Bu, aynı ortalama aktif saat gecikmesiyle günde 8640 istek yapan 10 saniyede bir saf döngüden onlarca kat azdır.

Proxy webhook'ların yanında nerede gerekli: giden yanıtlar ve üçüncü taraf API çağrıları

Yazıyı «proxy'nin webhook'larla ilgisi yok» düşüncesiyle bitirmek doğru olmaz. İlgisi var ve çok somut, sadece şemanın diğer tarafında. Bir olayı aldıktan sonra işleyiciniz neredeyse her zaman giden istekler yapar: işlemi doğrular, sipariş ayrıntılarını ek olarak sorar, veriyi başka bir sisteme gönderir, kullanıcıyı bilgilendirir. Tüm bu istekler gidendir ve işte burada proxy yerindedir.

Senaryo 1. Olayı ters istekle doğrulama

İyi güvenlik pratiği: webhook gövdesine körü körüne güvenmemek, imza doğrulamasından sonra nesneyi sağlayıcıdan tanımlayıcısıyla ek olarak sormak. Bu istek sunucunuzdan sağlayıcının API'sine gider. Sağlayıcı bölgesel olarak erişimi kısıtlıyor ya da istek kaynağının davranış analizini yapıyorsa, Proxeon üzerinden istenen bölgeden kararlı bir çıkış adresi trafik resmini öngörülebilir kılar.

Senaryo 2. İşleyiciden üçüncü taraf API'lere çağrılar

Bir pazaryerinin webhook işleyicisi kargo servisi API'sine, karşı taraf doğrulama servisine, harita API'sine çağrı yapabilir. Her birinin IP adresi başına kendi limitleri var. Entegrasyonları farklı çıkış adreslerine dağıtmak onları birbirinden yalıtır: bir entegrasyonun limitini tüketmesi diğerlerini felç etmez.

Senaryo 3. Giden trafik kimliğini ayırma

Bir sunucu birkaç bağımsız müşteriye veya projeye hizmet verdiğinde, dış API'lere giden trafiklerinin farklı adreslerden gitmesi yararlıdır. Bu teşhisi kolaylaştırır (adresten kimin isteği olduğu görülür) ve bir projenin sorunlarının diğerlerini etkileme riskini azaltır.

Örnek: alıcı doğrudan, giden çağrılar proxy üzerinden

Altın kural: webhook alıcı doğrudan genel adreste dinler, proxy yalnızca giden çağrılar için kullanılır. Alıcıyı proxy'ye «sarmalamaya» çalışmayın, yukarıda ele alınan tüm nedenlerle anlamsızdır.

import requests
from flask import Flask, request

app = Flask(__name__)

OUT_PROXY = 'http://user:pass@gate.proxeon.net:PORT'
outbound = requests.Session()
outbound.proxies = {'http': OUT_PROXY, 'https': OUT_PROXY}

@app.post('/webhook/orders')
def orders():
event = request.get_json()
# kabul doğrudan, proxy olmadan
order_id = event['order_id']
# giden doğrulama ve üçüncü taraf API çağrıları - proxy üzerinden
full = outbound.get(f'https://api.marketplace.example/orders/{order_id}',
timeout=(5, 20)).json()
outbound.post('https://api.delivery.example/shipments',
 json={'order': full}, timeout=(5, 20))
return '', 200

Birkaç pratik not. Giden çağrılar için ayrı bir Session tutun, proxy ayarları uygulamanın başka yerlerine sızmasın. Zaman aşımlarını açıkça belirtin: proxy üzerinden yol daha uzundur ve takılan giden bir çağrı webhook sağlayıcısına yanıtı geciktirmemelidir. İdeal olarak giden çağrıları HTTP isteği işleyicisinde değil, kuyruğu okuyan bir arka plan çalışanında yapın. Ve üçüncü taraf API sağlayıcısı adresinizi izin listesine almanızı istiyorsa, döndürülebilir değil statik çıkış adresli bir tarife kullanın.

Tablo: görev — uygun çözüm

Hepsini tek bir başvuru kaynağında toplayalım. Her tipik görev için proxy'nin bunu çözüp çözmediği ve yerine veya yanına ne kullanılması gerektiği belirtilmiştir.

• Görev: dış API'lere istenen bölgeden veya operatörden giden istekler yapmak. Çözüm: Proxeon proxy, gereksinimlere göre statik veya döndürülebilir tarife. Proxy'nin rolü: esas.
• Görev: üretimde ödeme ağ geçidinden webhook kabul etmek. Çözüm: genel adresli VPS, alan adı, TLS, imza doğrulamalı ve kuyruklu alıcı. Proxy'nin rolü: yalnızca işleyiciden giden çağrılar için.
• Görev: geliştirici makinesinde webhook kabulünü hata ayıklamak. Çözüm: sabitlenmiş alan adlı genel sunucuya ters tünel. Proxy'nin rolü: yok.
• Görev: mesajlaşma uygulamasından veya kuyruklu API'den olay almak, kod evde ya da mobil modem arkasında çalışıyor. Çözüm: getUpdates gibi metotlarla long polling, sağlayıcı kuyruğunu okuma. Proxy'nin rolü: giden istekler için isteğe bağlı.
• Görev: webhook ve kuyruk olmadan API'deki değişiklikleri izlemek. Çözüm: imleçli, koşullu istekli ve limitlere saygılı uyarlanabilir anket. Proxy'nin rolü: sağlayıcı limitleri çerçevesinde yükü çıkış adreslerine dağıtmak.
• Görev: mobil modemle bağlı bilgisayarda webhook kabul etmek. Çözüm: CGNAT nedeniyle doğrudan imkânsız; ters tünel veya kuyruk kullanın. Proxy'nin rolü: yok.
• Görev: bir sunucudaki birkaç entegrasyon üçüncü taraf API limitlerinde birbirine engel olmamalı. Çözüm: entegrasyon başına ayrı Proxeon çıkış adresleri ve ayrı kuyruklar. Proxy'nin rolü: giden kısım için esas.
• Görev: üçüncü taraf API adresin izin listesine alınmasını istiyor. Çözüm: statik çıkış adresi; webhook kabulü için sunucunuzun genel adresi. Proxy'nin rolü: giden kısım için statik tarife.
• Görev: ev yönlendiricisinde genel adres almak. Çözüm: komşu konu, ev sağlayıcısına bağlı; yalnızca ekipmanda gerçek genel adres varsa uygulanabilir. Proxy'nin rolü: yok.

Tipik hatalar: yapılmaması gerekenler

En sık basılan tırmıkları toplayalım. Bazıları saatlerce hata ayıklamaya, bazıları kayıp ödemelere mal olur.

Hata 1. Proxy adresini webhook URL'si olarak girmek

Yukarıda ayrıntılı ele alındı ama tekrarlayalım: proxy'nin çıkış adresinde sizin dinleyiciniz yok. Sağlayıcı zaman aşımı veya bağlantı reddi alır, birkaç başarısızlıktan sonra aboneliği kapatır. Bazı sağlayıcılar tekrarlayan hatalarda URL'yi uzun süre bloklar.

Hata 2. Yerel veya özel adres girmek

http://192.168.1.10:8080/hook veya http://localhost/hook biçimindeki URL yalnızca kendi ağınızda yönlendirilir. Sağlayıcı fiziksel olarak ona ulaşamaz. Çoğu sağlayıcı bu tür URL'leri abonelik kaydında hemen reddeder, ama hepsi değil.

Hata 3. Kendinden imzalı sertifika veya düz HTTP

Webhook sağlayıcıları sertifikayı kontrol eder. Kendinden imzalı veya süresi geçmiş sertifika sessiz teslimat reddine yol açar. TLS'siz düz HTTP'ye çoğu sağlayıcı hiç izin vermez.

Hata 4. HTTP işleyicisi içinde uzun işleme

İşleyici sağlayıcıya yanıt vermeden önce üç dış API'den veri çekip veritabanına yazıyorsa bekleme zaman aşımını rahatlıkla aşar. Sağlayıcı teslimatı başarısız sayar ve tekrarlar. Aynı olayı birkaç kez işlersiniz. Yanıt yüz milisaniyeler içinde gitmeli, işleme kuyruğa alınmalı.

Hata 5. İdempotentliğin olmaması

Tekrar teslimatlar istisna değil normaldir. İşlenmiş tanımlayıcıları hesaba katmazsanız siparişi iki kez oluşturur, bildirimi iki kez gönderir veya muhasebe sisteminde tahsilatı iki kez yaparsınız.

Hata 6. Webhook gövdesine körü körüne güvenmek

Genel URL herkese açıktır. İmza doğrulaması olmadan herkes size sahte bir «ödeme geçti» olayı gönderebilir. HMAC doğrulayın ve kritik işlemler için nesneyi sağlayıcıdan ek olarak sorun.

Hata 7. Üretimde geçici tünel adresi

Tünel hizmetinin rastgele oluşturulmuş alan adı yeniden başlatmada değişir. Sağlayıcı aboneliği eski URL'ye bağlı kalır. Biri fark edene kadar olaylar kaybolur. İşletimde tünel yalnızca sabitlenmiş alan adı ve izleme ile kabul edilebilir.

Hata 8. Sabit kısa aralıklı anket

İmleç ve koşullu istek olmadan saniyede bir, 429'a ve anahtarın geçici bloklanmasına giden doğrudan yoldur. Daha kötüsü, bloklandığında hiçbir şey almazsınız ve teslimat gecikmesi sonsuz olur.

Hata 9. Giden çağrıları zaman aşımı olmadan proxy üzerinden yapmak

Proxy araya bir düğüm ekler. Açık zaman aşımları olmadan takılan giden çağrı çalışanı tutar, HTTP işleyicisi içinde yapılmışsa sağlayıcıya yanıtı da bozar. Bağlantı ve okuma zaman aşımını her zaman ayrı ayrı belirtin.

Hata 10. SOCKS5'teki BIND komutunun sizi sunucu yapacağını sanmak

Belirtimi okuyanlarda görülür. Ticari düğümlerde komut genellikle uygulanmamıştır, uygulandığı yerde de kısa süreliğine tek bağlantı verir. Webhook'lar için uygun değildir.

Vaka ve sonuçlar: pratikte nasıl görünüyor

Tipik entegrasyon geliştirme durumlarından derlenmiş üç hikâye. Rakamlar yuvarlanmış, ama büyüklük sırası gerçek.

Vaka 1. E-ticaret mağazasının ödeme bildirimleri

Küçük bir ekip, site kurucusu üzerinde mağaza geliştiriyordu ve mobil modem arkasındaki ofis bilgisayarında çalışan Python'da ödeme işleyicisi yazıyordu. Ödeme sağlayıcısının ayarlarına mobil proxy adresini girdiler, çünkü «o da genel ya». Sağlayıcı teslimatı 1, 5, 30 dakika, 2 saat programıyla tekrarladı, sonra aboneliği kapattı. Bir haftada, gerçekte geçmiş ödemelere karşılık «ödeme bekliyor» durumunda yaklaşık 40 sipariş birikti ve manuel mutabakat gerekti.

Çözüm: asgari bir VPS kiralandı, imza doğrulamalı ve Redis kuyruklu alıcı kuruldu, işleyici yerelde kaldı ve kuyruğu giden bağlantıyla okuyor. Ayrıca saatte bir, son günün ödeme listesini imleçle tarayan bir mutabakat anketi çalışıyor ve herhangi bir arızadan kaçan olayları yakalıyor. Sonuç: sonraki üç ay boyunca sağlayıcı ile muhasebe arasında hiçbir tutarsızlık görülmedi, ödemeden sipariş durumu değişimine kadar geçen süre ortalama 1,2 saniye oldu.

Vaka 2. Modemli dizüstünde destek botu

Bir geliştirici iç ekibi için bot yazıyordu ve onu mobil modemle bağlı dizüstünden çalıştırmak istiyordu. Webhook'u proxy adresine kaydetme girişimi beklendiği gibi başarısız oldu. Timeout 50 saniye ile getUpdates üzerinden long polling'e geçiş sorunu yarım saatte çözdü: bağlantı giden, ne modem ne CGNAT ona engel. İstek tüketimi tam boşta günde yaklaşık 1700, bu API için önemsiz. Yalnızca webhook yapabilen harici CRM entegrasyonunun hata ayıklaması için sabitlenmiş alan adlı kiralık sunucuya ters SSH tüneli kuruldu, üretimde alıcı sunucunun kendisine taşındı.

Vaka 3. Pazaryerinde webhook'suz durum izleme

Bir pazaryerindeki birkaç mağazanın operatörü, webhook'u olmayan bir API üzerinden sipariş durumlarını izliyordu. Her mağaza için 10 saniyede bir saf anket günde yaklaşık 50 bin istek üretiyor ve düzenli olarak 429'a takılıyordu. Altıncı bölümdeki ilkelerle yeniden tasarlandıktan sonra (updated_after imleci, 15 saniyeden 10 dakikaya uyarlanabilir aralık, Retry-After işleme, sipariş kimliğiyle idempotentlik) yük günde yaklaşık 4 bin isteğe düştü, yani 12 kattan fazla azaldı, çalışma saatlerinde ortalama değişiklik tespiti gecikmesi 20 saniye içinde kaldı. Pazaryeri API'sine ve kargo servisi API'sine giden istekler ayrı Proxeon çıkış adreslerine dağıtıldı, böylece bir entegrasyonun limitleri diğerini etkilemiyor ve loglarda kaynak adresten hangi mağazanın istek başlattığı hemen görülüyor.

SSS: proxy ve webhook kabulü hakkında sık sorulanlar

Statik tahsisli bir proxy IP'm varsa, ona webhook kabul edebilir miyim?

Hayır. Adresin statikliği, giden istekler ve üçüncü taraf API'lerdeki izin listeleri için öngörülebilirlik sorununu çözer. Ama o adreste hâlâ sizin kodunuzu dinleyen port yok: orada proxy yazılımı çalışıyor, sizin alıcınız değil. Kabul için kontrol ettiğiniz bir sunucu gerekir.

Dışarıdan adreslenemiyorsa IP kontrol servisleri neden genel adresi gösteriyor?

Kontrol servisi, kendisine gelen isteğin kaynak adresini, yani operatörün NAT ağ geçidinin ya da proxy düğümünün adresini görür. Bu, trafiğin çıktığı adrestir, size girilebilecek adres değil. Adresin dışarıdan görünürlüğü ile ona bağlantı başlatabilme farklı özelliklerdir.

BIND komutlu SOCKS5 üzerinden webhook kabul edilebilir mi?

Pratikte hayır. Komut belirtimde tanımlıdır, ama ticari düğümlerde güvenlik gerekçesiyle genellikle uygulanmaz, uygulandığı yerde de aynı konağa giden bağlantıdan sonra kısa süreliğine tek gelen bağlantı kabul eder. TLS'li kalıcı bir webhook URL'si kaydetmek için uygun değildir.

Ters tünel ile yönlendiricideki port yönlendirme arasındaki fark ne?

Port yönlendirme yalnızca ekipmanınızda gerçek genel adres varsa çalışır: yönlendirici gelen bağlantıyı alıp ağ içine iletir. Ters tünel sizden genel adres istemez: makineniz kendisi genel sunucuya giden bağlantı başlatır, o da sizin adınıza dinler. CGNAT'lı mobil ağlarda birinci yol prensipte mümkün değildir, ikinci çalışır.

Ters tünel üretim için güvenilir mi?

Şu koşullarla: sabitlenmiş alan adı, otomatik yeniden bağlanma, bağlantı canlılık kontrolü, kesinti izleme ve genel tarafta erişilemezlik süresince tamponlama. Bu koşullar olmadan tünel geliştirme için uygundur, işletim için değil. Kritik entegrasyonlar için alıcıyı doğrudan genel sunucuya yerleştirmek daha güvenilirdir.

Anket gecikme açısından kesinlikle webhook'lardan kötü değil mi?

Long polling webhook'larla kıyaslanabilir gecikme verir: olay ortaya çıktığı anda gelir. Normal uyarlanabilir anket aktif saatlerde minimum aralık kadar, sessizlikte maksimuma kadar gecikme verir. Birçok iş süreci için 15–30 saniye gecikme kabul edilebilir. Webhook'lar ise gelen bağlantının ulaştırılabilirliğine bağlıdır ve kayıplara karşı mutabakat mekanizması gerektirir; bu yüzden gerçek sistemlerde anket çoğu zaman webhook'ları tamamlar, onlara yenilmez.

Zaten genel adresli VPS'im varsa proxy gerekli mi?

Webhook kabulü için gerekli değil. İşleyicilerden giden istekler için, üçüncü taraf API kaynak bölgesine duyarlıysa, farklı entegrasyonların limitlerini adreslere göre yalıtmak gerekiyorsa veya isteklerin belirli bir operatörün mobil abonesi trafiği gibi görünmesi isteniyorsa yararlıdır. Bu ayrı bir görevdir ve ayrı bir araçla çözülür.

Sağlayıcının webhook'u göndermeye çalıştığından nasıl emin olurum?

Çoğu sağlayıcı yanıt kodları ve hata nedenleriyle teslimat günlüğü tutar. Önce ona bakın: alan adı çözülüyor mu, TLS kuruluyor mu, sunucunuz hangi kodu kaç milisaniyede döndürdü, hepsi görünür. Yerel teşhis için başlıkları ve gövdeyi kaydeden asgari bir HTTP sunucusu çalıştırın ve tüneli ona yönlendirin.

Sağlayıcı 3 saniyede yanıt istiyor ama işleme 10 saniye sürüyorsa ne yapmalı?

Kabul ile işlemeyi ayırın. Alıcı imzayı doğrular, olayı kuyruğa koyar ve onlarca milisaniyede 200 döner. Çalışan kuyruğu okur ve olayı gerektiği kadar işler, üçüncü taraf API'lere giden çağrıları gerekirse proxy üzerinden, açık zaman aşımları ve tekrarlarla yapar.

Sonuç: doğru model ve sonraki adımlar

Yazıyı tek bir düşünceye indirgersek şöyle der: proxy ağa nereden çıktığınızı değiştirir, ama size girilebilecek bir yer yaratmaz. Bağlantı yönü temel bir özelliktir ve hiçbir tarife onu tersine çevirmez. Proxeon mobil proxy giden isteklerinizi belirli bir operatörün abonesinin trafiği yapar, tam da bu yüzden aboneye özgü dışarıdan adreslenememe özelliğini miras alır: CGNAT arkasında dinleyen port yoktur ve adres ağın doğası gereği değişir.

Webhook kabulü başka bir sınıf araçla çözülür. Alan adlı ve TLS'li genel sunucu, işletim için temel seçenektir. Ters tünel, geliştirme ve kodun yerel çalışması gereken durumlar içindir. Sağlayıcı tarafında olay kuyruğu ve long polling, sağlayıcı sunduğunda en zarif seçenektir. İmleçli, koşullu istekli ve limitlere saygılı uyarlanabilir anket ise, düzgün tasarımlandığında pratik değer açısından webhook'lardan geri kalmayan evrensel bir yedek yoldur.

Proxy ise şemaya yerinde döner: işleyicilerden giden çağrılarda, olayların ters istekle doğrulanmasında, farklı entegrasyonların limitlerinin çıkış adreslerine göre yalıtılmasında. Alıcı doğrudan dinler, gidenler proxy üzerinden gider — bu formül gerçek görevlerin büyük çoğunluğunu kapatır.

Okuduktan sonra yapılacaklar

1. Her webhook aboneliğinizin ayarlarını açın ve URL'nin nereyi gösterdiğini kontrol edin: kontrol ettiğiniz ve 443 portunu geçerli sertifikayla dinleyen bir sunucu olmalı.
2. Alıcının hızlı yanıt verdiğinden, işlemenin kuyruğa alındığından emin olun; imza doğrulaması ve işlenmiş tanımlayıcı takibi var mı bakın.
3. Webhook'suz entegrasyonlar için anketi altıncı bölümdeki kontrol listesine göre yeniden yazın ve istek sayısı ile gecikmenin nasıl değiştiğini ölçün.
4. İşleyicilerden giden çağrıları gözden geçirin: kararlı bölgesel adres veya limit yalıtımı gereken yerlerde ayrı oturumlu ve açık zaman aşımlı proxy bağlayın.
5. Kritik webhook'lar için güvence olarak mutabakat anketi ekleyin: saatte bir son aralıktaki olayları sorgulayın ve işlenenlerle karşılaştırın.

Görevleri giden ve gelen diye ayırmak titizlik değil, tanımı gereği çalışamayacak şeylerde hata ayıklamaya saat harcamayı bırakıp çalışacak şeylere yönlendirmenin yoludur.