---
title: "API için Statik IP: IP Yetkilendirme Hatası Nasıl Çözülür?"
description: "IP yetkilendirme hatası, isteğiniz servise kayıtlı olmayan bir adresten çıktığında görülür. Çıkış IP'nizi bulmayı ve dört sabit IP seçeneğini anlatıyoruz."
url: https://proxynet.io/tr/blog/static-ip-for-api-access
date: 2026-09-19
author: "Acar Diveroli"
category: "Nasıl Yapılır, Proxy 101"
lang: tr
---

# API için Statik IP: IP Yetkilendirme Hatası Nasıl Çözülür?

Entegrasyonu dün akşam çalıştırdınız, sipariş listesi geldi, SMS gitti. Bu sabah aynı kod, aynı anahtarla "IP yetkilendirme gerekiyor" ya da çıplak bir `403` dönüyor. Kodda değişen bir şey yok. Değişen, isteğin internete çıktığı adres: modem gece yeniden bağlandı, evden çalışan arkadaşınız kendi hattından denedi ya da uygulama başka bir sunucuya taşındı. Karşıdaki servis ise yalnız önceden bildirilen adresi tanıyor.

Bu yazıda API'lerdeki IP yetkilendirmenin nasıl çalıştığını, uyarının hangi durumlarda çıktığını ve servisin gördüğü çıkış IP'sini nasıl öğreneceğinizi anlatıyoruz. Ardından sabit bir çıkış adresi edinmenin dört yolunu (internet sağlayıcınızdan statik IP, sabit IP'li sunucu, NAT gateway ve statik proxy) tek tabloda karşılaştırıyoruz. Ödeme, sağlık ve e-fatura entegrasyonlarında hangi yolun seçilmemesi gerektiğine ayrı bir başlık ayırdık. Sonunda çıkış adresinizi doğrulayan, çalıştırılmış bir Python ve Node.js örneği var.

> **Not: Kısa cevap**
>
> IP yetkilendirme isteyen bir API, isteği yalnız kendisine kayıtlı adreslerden kabul eder. Hata, isteğiniz başka bir adresten çıktığında görülür: ev ve ofis hatlarının çoğu dinamik IP kullanır, bir kısmı da CGNAT arkasındadır. Önce isteğin gerçekten çıktığı makineden çıkış IP'nizi öğrenin ve kayıtlı adresle karşılaştırın. Kalıcı çözüm, değişmeyen bir çıkış adresidir. Hassas veri taşıyan entegrasyonlarda bu adres kendi hattınız ya da kendi sunucunuz olmalıdır; test ortamları ve hassas veri taşımayan istemcilerde statik proxy de iş görür.

## API'lerde IP yetkilendirme nedir?

IP yetkilendirme (izinli IP listesi, İngilizce belgelerde "IP whitelist" ya da "allowlist"), bir servisin gelen isteği içeriğine bakmadan önce kaynak adresine göre elemesidir. Servisin panelinde ya da destek ekibinin kayıtlarında hesabınıza bağlı bir adres listesi bulunur. İstek bu listedeki bir adresten geliyorsa API anahtarınız kontrol edilir; gelmiyorsa anahtarınız doğru olsa bile istek reddedilir.

Bu kontrol API anahtarının yerine geçmez, ona eklenir. Anahtarınız bir depoya yanlışlıkla yüklense ya da bir çalışanın bilgisayarından sızsa bile, onu ele geçiren kişi sizin adresinizden çıkmadığı sürece kullanamaz. Bakılan şey bir HTTP başlığı değil, TCP bağlantısının karşı ucundaki adrestir; `X-Forwarded-For` gibi bir başlık ekleyerek kaynak adresi değiştiremezsiniz.

Burada sık karışan iki yönü ayıralım. [Proxy Kimlik Doğrulama: User:Pass ve IP Whitelist](/tr/blog/proxy-authentication-methods) yazımızda anlattığımız listede adresinizi **proxy sağlayıcınıza** bildirirsiniz ve amaç proxy'ye şifresiz bağlanmaktır. Bu yazının konusu ters yöndür: adresinizi, verisine ulaşmak istediğiniz **üçüncü taraf servise** bildirirsiniz. Mekanizma aynıdır, muhatap farklıdır.

## Servisler çıkış IP'nizi hangi biçimlerde ister?

Uygulamada üç biçimle karşılaşırsınız.

**Zorunlu kayıt.** Servis, adresinizi tanımlamadan erişim açmaz. Tanımlamayı çoğu zaman siz yapamazsınız: bir destek talebi açılır, adres karşı tarafta elle girilir. Bankaların ve kamu kurumlarının entegrasyonlarında, bazı pazaryeri ve kargo API'lerinde bu biçim yaygındır. Bazı servislerde kural yalnız bir ortam için geçerlidir: birçok pazaryeri API'sinde test ortamına erişim için ağ çıkış adresinizi bildirmeniz istenir, canlı ortamda aynı kural aranmaz. Hangi ortamda hangi kuralın geçerli olduğunu yalnız servisin kendi geliştirici dokümanı söyler.

**İsteğe bağlı kısıtlama.** Kısıtlamayı servis değil siz açarsınız. Birçok SMS/mesajlaşma ve e-posta servisinde panelde "yalnız şu adreslerden gelen istekleri kabul et" diye bir alan bulunur; sağlayıcıların hazırlık rehberleri bu kısıtlamayı önerilen bir güvenlik adımı olarak sayar. Bu biçimde hatanın nedeni çoğu zaman unutulmuş bir ayardır: kısıtlamayı kendiniz açmışsınızdır, sunucu taşınınca eski adres listede kalmıştır.

**Ters yön.** Webhook gibi akışlarda isteği servis size gönderir ve izin listesini siz tutarsınız: servisin dokümanında yayımladığı adresleri kendi güvenlik duvarınıza eklersiniz.

Kurallar servisten servise ve zamanla değişir. Hangi ortamda, kaç adrese, hangi yolla izin verildiğini servisin kendi geliştirici dokümanından okuyun.

## "IP yetkilendirme gerekiyor" uyarısı hangi durumda çıkar?

Uyarının tek bir biçimi yoktur. Servisler aynı durumu farklı kodlarla bildirir:

- **Açık bir mesaj.** Yanıt gövdesinde "IP yetkilendirme gerekiyor" ya da "IP not allowed" benzeri bir metin. En kolay teşhis edilen durumdur.
- **`403 Forbidden`.** Sunucu isteği anlamış ama reddetmiştir. [MDN'in 403 sayfasının](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/403) da belirttiği gibi bu kodda kimlik bilgisini yeniden göndermek sonucu değiştirmez.
- **`401 Unauthorized`.** Bazı servisler adres uyuşmazlığını kimlik hatasıyla aynı kodla bildirir. Anahtarınızı üç kez yenileyip hâlâ `401` alıyorsanız adrese bakın.
- **`503` ya da zaman aşımı.** Eleme uygulamadan önce, güvenlik duvarında yapılıyorsa hiç anlamlı yanıt gelmeyebilir. Bazı sağlayıcılar test ortamında alınan `503` hatasını doğrudan eksik IP yetkilendirmesine bağlar.

Tersi de olur: her `403` adres sorunu değildir. Bazı API'ler zorunlu bir başlığı, örneğin `User-Agent` bilgisini taşımayan istekleri de aynı `403` ile reddeder. Adresi değiştirmeden önce yanıt gövdesini okuyun ve isteği dokümandaki örnekle başlık başlık karşılaştırın. Durum kodlarının genel okumasını [Scraping'de HTTP Hata Kodları](/tr/blog/http-status-codes-web-scraping) yazımızda anlattık.

## Çıkış IP'nizi nasıl öğrenirsiniz?

Servise bildirilecek adres bilgisayarınızın ağ ayarlarında gördüğünüz `192.168.x.x` adresi değildir; o adres yalnız yerel ağınızda geçerlidir. Servisin gördüğü, modeminizin ya da sunucunuzun internete çıktığı genel adrestir. Doğru adresi bulmak için:

1. **İsteği atan makinede ölçün.** Entegrasyon bir sunucuda çalışıyorsa adresi kendi dizüstü bilgisayarınızın tarayıcısından değil, o sunucunun terminalinden öğrenin.
2. **Bir yankı servisine istek atın.** `curl https://api.ipify.org` ya da `curl https://checkip.amazonaws.com` yanıt olarak yalnız gördüğü adresi döndürür.
3. **Uygulamanın kullandığı yoldan ölçün.** Uygulamanız bir proxy ya da kurumsal VPN üzerinden çıkıyorsa ölçümü de aynı yoldan yapın; doğrudan ölçüm farklı bir adres gösterir.
4. **IPv6'yı kontrol edin.** `curl https://api64.ipify.org` hattınızda IPv6 varsa IPv6 adresinizi döndürür. Servisin alan adı IPv6 destekliyorsa isteğiniz oradan çıkıyor olabilir; bildirdiğiniz IPv4 adresi bu durumda hiç görülmez.
5. **Ölçümü tekrarlayın.** Aynı komutu modemi yeniden başlattıktan sonra ve ertesi gün bir kez daha çalıştırın. Adres değişiyorsa hattınız dinamiktir.

## Kayıtlı IP neden tutmuyor?

Adresi doğru bildirdiniz, bir süre çalıştı, sonra bozuldu. Olası nedenler:

- **Dinamik IP.** Ev ve küçük ofis hatlarının çoğunda adres modem her yeniden bağlandığında ya da kira süresi dolduğunda değişebilir. Ayrımın bütününü [Statik IP ve Dinamik IP Farkı](/tr/blog/static-ip-vs-dynamic-ip) yazımızda anlattık.
- **CGNAT.** Operatör aynı genel adresi çok sayıda aboneye paylaştırıyorsa gördüğünüz adres size ait değildir ve bir sonraki bağlantıda başka bir havuz adresine düşebilirsiniz. Böyle bir adresi bir API'ye kaydetmek, aynı havuzdaki başka abonelere de kapı açmak demektir. Nasıl anlaşılacağı [CGNAT Nedir?](/tr/blog/what-is-cgnat) yazımızda.
- **Mobil hotspot ya da açık kalmış VPN.** Telefondan paylaşılan bağlantı da bilgisayarda açık unutulan VPN istemcisi de isteği bambaşka bir adresten çıkarır.
- **Birden fazla çıkış noktası.** Otomatik ölçeklenen konteynerler ve özel ağa bağlanmamış serverless fonksiyonlar her çalıştırmada bulut sağlayıcısının geniş havuzundan farklı bir adresle çıkabilir. Bulut sunucusuna otomatik atanan genel adres de çoğu sağlayıcıda sunucu durdurulup başlatıldığında değişir; kalıcı olması için rezerve bir adres ayırmanız gerekir.

## Sabit çıkış IP'si için dört seçenek

Kalıcı çözüm, servise bir kez bildireceğiniz ve değişmeyen bir adrestir. Dört yolu vardır; hangisinin doğru olduğu kodun nerede çalıştığına ve hangi veriyi taşıdığına bağlıdır.

| Seçenek | Adres kimin? | Kurulum | Kim yönetir? | Ne zaman doğru seçim? |
|---|---|---|---|---|
| İnternet sağlayıcınızdan statik IP | Aboneliğinize tanımlı, sözleşmesi sizde | Sağlayıcıya başvuru; hat başına tek adres | Siz ve sağlayıcınız | Kod ofisteki bilgisayarda ya da sunucuda çalışıyorsa; kurum "kendi hattınızın adresi" diyorsa |
| Sabit IP'li VPS ya da bulut sunucu | Sunucuyu kiraladığınız hesaba rezerve | Sunucu kurulur, uygulama oraya taşınır | Siz | Kesintisiz çalışan entegrasyonlar, zamanlanmış görevler, webhook alan uygulamalar |
| Bulut NAT gateway | Bulut hesabınıza rezerve | Özel ağdaki bütün kaynaklar tek çıkışa yönlendirilir | Siz (ağ yapılandırması gerekir) | Birden fazla sunucu, konteyner ya da serverless fonksiyon aynı adresten çıkmalıysa |
| Statik (ISP) proxy | Proxy sağlayıcısının; size ayrılmış | Dakikalar; yalnız istemciye proxy adresi yazılır | Proxy sağlayıcınız | Test ve geliştirme ortamı, hassas veri taşımayan API istemcileri, dağınık çalışan ekibin tek adresten çıkması |

**İnternet sağlayıcınızdan statik IP.** Araya yeni bir sistem girmez, mevcut hattınızın adresi sabitlenir. Adres o hatta bağlıdır; evden çalışan geliştirici ya da başka şehirdeki şube bu adresten çıkamaz. Başvuru adımları kardeş yazının "Sabit IP nasıl alınır?" bölümünde.

**Sabit IP'li sunucu.** Gece stok eşitleme ya da sipariş çekme gibi sürekli çalışan bir işi ofis bilgisayarında değil, rezerve adresli bir sunucuda çalıştırmak hem adres hem süreklilik sorununu çözer.

**NAT gateway.** Her makineye ayrı adres bildirmek yerine hepsini tek bir çıkış kapısına bağlarsınız. AWS'nin [NAT gateway belgesine](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) göre genel bir NAT gateway oluşturulurken ona bir Elastic IP bağlanır ve özel alt ağlardaki kaynaklar internete bu kapıdan çıkar. Google Cloud'un [Cloud NAT belgesi](https://docs.cloud.google.com/nat/docs/overview) de NAT adresleri elle atandığında bu adreslerin karşı tarafla paylaşılabileceğini, örnek olarak da yalnız bilinen adreslerden bağlantı kabul eden servisleri anar.

**Statik proxy.** İstemciniz internete size ayrılmış, değişmeyen bir proxy adresinden çıkar ve servise bu adresi bildirirsiniz. Hattınızın dinamik ya da CGNAT arkasında olması fark etmez, çünkü servisin gördüğü adres proxy'nin adresidir. Karşılığında trafiğinizin yoluna üçüncü bir taraf girer; bunun nerede kabul edilemez olduğu bir sonraki başlıkta.

## Ödeme, sağlık ve e-fatura entegrasyonlarında neden proxy kullanılmaz?

Sanal POS ve ödeme kuruluşu API'leri, sağlık kurumlarının provizyon ve kayıt sistemleri, e-fatura ve e-defter entegrasyonları ile kamu kurumlarının bildirim servisleri ayrı bir sınıftır. Bu entegrasyonlarda çıkış adresi olarak **üçüncü taraf bir proxy önermiyoruz**; buna kendi ürünümüz de dahildir. Doğru yol, internet sağlayıcınızdan alacağınız statik IP, kendi sunucunuzun rezerve adresi ya da bulut hesabınızdaki NAT gateway'dir. Nedenleri:

1. **Kayıt altına alınan adres sizin olmalıdır.** Bu kurumlar adresi bir güvenlik ayarı olarak değil, "bu işlem şu işletmenin şu sisteminden geldi" diyen bir kayıt olarak tutar. Proxy adresi sağlayıcıya aittir ve siz hizmeti bıraktığınızda başka bir müşteriye verilebilir. Karşı tarafta silinmesi unutulan bir izin kaydı, adresin yeni kullanıcısını hesabınıza bir adım yaklaştırır.
2. **Zincire bir halka eklenir.** HTTPS'te proxy isteğin içeriğini göremez: bağlantı `CONNECT` tüneliyle kurulur, şifreleme sizinle API arasında kalır. Buna karşın proxy hangi sunucuya, ne zaman, ne kadar veri gönderdiğinizi görür ve bir arızada ödeme ya da fatura akışınız kontrol etmediğiniz bir sistem yüzünden durur.
3. **Sözleşme ve denetim.** Bu entegrasyonların sözleşmeleri ve tabi oldukları düzenlemeler, verinin hangi sistemlerden geçtiğini bilmenizi ve belgeleyebilmenizi ister. Kurumun şartnamesini okuyun; birçoğu adresin işletmenize ait bir hat ya da sunucu olmasını açıkça şart koşar.
4. **Gerek yoktur.** Bu sistemler zaten kesintisiz çalışan bir sunucu ister. Sunucunuz varsa sabit adresiniz de vardır.

Aynı sınır kişisel veri taşıyan her entegrasyon için geçerlidir: müşteri kimliği, sağlık ya da kart verisi akan bir hatta çıkış noktası kendi altyapınız olsun.

## Statik proxy hangi durumda uygun?

Geriye, hassas veri taşımayan ve hızlı çözüm isteyen durumlar kalır:

- **Test ve geliştirme ortamı.** Servis test ortamı için adres istiyor, geliştiriciler ise evden, dinamik hatlardan çalışıyor. Herkesin hattına statik IP almak yerine ekip tek bir proxy adresinden çıkar, servise o adres bildirilir.
- **Dağınık ekip, tek izinli adres.** Aynı iç aracı üç farklı şehirden kullanan ekip, servise üç ayrı adres bildirmek zorunda kalmaz.
- **Geçiş dönemi.** Statik IP başvurunuz ya da sunucuya taşınma bitene kadar entegrasyonun çalışması gerekiyor.
- **CGNAT arkasındaki küçük işletme.** Hat paylaşılan adresle çalışıyor ve sağlayıcı o abonelikte statik IP sunmuyor.

Her durumda önce servisin kullanım şartlarını okuyun: isteklerin doğrudan kendi altyapınızdan gelmesini şart koşan serviste proxy seçenek olmaktan çıkar.

Seçim yaparken iki özelliğe bakın. Adres **size ayrılmış** olmalıdır: paylaşımlı bir adresi bir API'ye kaydederseniz aynı adresi kullanan başkaları da o filtreden geçer. Adres **statik** olmalıdır; dönen (rotating) bir havuzun adresleri tanım gereği değişir. Kavramın ayrıntısı [Statik Proxy](https://proxynet.io/tr/static-proxy) sayfamızda. Proxynet'te bu ihtiyacı [ISP Proxy](https://proxynet.io/tr/static-isp-residential-proxy) ve [Datacenter Proxy](https://proxynet.io/tr/datacenter-proxy) karşılar: ikisinde de adres yalnız size tahsis edilir ve siz bırakana kadar değişmez. ISP adresinde aylık taban fiyat ₺49, datacenter adresinde ₺35 seviyesindedir. API istemcileri için veri merkezi adresi çoğu zaman yeterlidir; servis veri merkezi adres bloklarını ayrıca kısıtlıyorsa ISP adresi seçilir.

## Statik proxy ile tek çıkış adresi nasıl kurulur?

1. Size ayrılmış statik bir proxy adresi alın.
2. Aşağıdaki komutla çıkış adresini ölçün. Servise bildireceğiniz adres bu yanıttır; komutu birkaç saat arayla yineleyip adresin aynı kaldığını görün:

   ```bash
   curl -x http://user:pass@pr.proxynet.io:8000 https://api.ipify.org
   ```

3. Bu adresi API sağlayıcısına bildirin (panel alanı ya da destek talebi). Tanımın etkinleşmesi servise göre dakikalar ya da saatler alabilir; süreyi servisin dokümanından öğrenin.
4. İstemcinizde proxy'yi tanımlayın. Postman'de ayar ekranını [Postman Proxy Ayarları](/tr/blog/postman-proxy), komut satırında [cURL ile Proxy Nasıl Kullanılır?](/tr/blog/curl-proxy), uygulama kodunda [Node.js'te Proxy Kullanımı](/tr/blog/nodejs-proxy) yazılarımız adım adım anlatır.
5. API adresini her zaman `https://` ile çağırın. Tünel içindeki TLS bağlantısı doğrudan API sunucusuyla kurulur; anahtarınız ve veriniz proxy'ye açık gitmez.

## Çıkış IP'sini kodla doğrulamak

Adres bir kez doğru görünüp sonra değişiyorsa tek ölçüm yanıltır. Aşağıdaki betik iki ayrı yankı servisine üç tur istek atar, her ölçümde yeni bir bağlantı açar ve gördüğü bütün adresleri servise bildirdiğiniz adresle karşılaştırır. Uyuşmazlıkta `1` koduyla çıktığı için dağıtım hattınıza (CI) eklenebilir. `203.0.113.10` belgeleme için ayrılmış örnek bir adrestir, yerine kendi adresinizi yazın.

```python
import sys
import time

import requests

PROXY_URL = "http://user:pass@pr.proxynet.io:8000"
EXPECTED_IP = "203.0.113.10"  # API sağlayıcısına bildirdiğiniz adres
ECHO_URLS = ["https://api.ipify.org", "https://checkip.amazonaws.com"]
ROUNDS = 3

def egress_ip(url):
    # Her ölçüm yeni bir oturum açar: açık kalan tünel yeniden kullanılırsa
    # değişen bir çıkış adresi gözden kaçar.
    with requests.Session() as session:
        session.trust_env = False  # kabuktaki HTTP_PROXY / NO_PROXY karışmasın
        session.proxies = {"http": PROXY_URL, "https": PROXY_URL}
        response = session.get(url, timeout=15)
        response.raise_for_status()
        return response.text.strip()

def main():
    seen = set()
    for round_no in range(1, ROUNDS + 1):
        for url in ECHO_URLS:
            ip = egress_ip(url)
            seen.add(ip)
            print(f"tur {round_no}  {url:<32} {ip}")
        time.sleep(2)

    if seen == {EXPECTED_IP}:
        print(f"TAMAM: bütün istekler {EXPECTED_IP} adresinden çıktı")
        return 0
    print(f"UYUŞMUYOR: beklenen {EXPECTED_IP}, görülen {sorted(seen)}")
    return 1

if __name__ == "__main__":
    sys.exit(main())
```

Betiği yerel bir test proxy'si üzerinden çalıştırdık: altı ölçümün her biri ayrı bir `CONNECT` tüneli açtı, adres beklenenle aynıyken betik `0`, farklıyken `1` koduyla çıktı. Şifreyi bilerek yanlış yazdığımızda Requests, `407` içeren bir `ProxyError` fırlattı; kimlik hatası sessizce doğrudan bağlantıya düşmez. Proxy kullanmıyorsanız (statik IP'li hat ya da sunucu) `session.proxies` satırını silmeniz yeterlidir; betik bu kez makinenin kendi çıkış adresini denetler.

Node.js tarafında ek paket kurmadan aynı kontrol yapılabilir. Güncel Node.js sürümlerinde yerleşik `fetch`, `NODE_USE_ENV_PROXY=1` verildiğinde `HTTPS_PROXY` değişkenini okur (ayrıntısı Node.js yazımızda):

```js
const EXPECTED_IP = process.env.EXPECTED_IP ?? "203.0.113.10";
const ECHO_URLS = ["https://api.ipify.org", "https://checkip.amazonaws.com"];

const seen = new Set();
for (const url of ECHO_URLS) {
  const response = await fetch(url, { signal: AbortSignal.timeout(15_000) });
  if (!response.ok) throw new Error(`${url}: HTTP ${response.status}`);
  const ip = (await response.text()).trim();
  seen.add(ip);
  console.log(url.padEnd(32), ip);
}

const ok = seen.size === 1 && seen.has(EXPECTED_IP);
console.log(ok ? `TAMAM: ${EXPECTED_IP}` : `UYUŞMUYOR: beklenen ${EXPECTED_IP}, görülen ${[...seen].join(", ")}`);
process.exitCode = ok ? 0 : 1;
```

```bash
NODE_USE_ENV_PROXY=1 HTTPS_PROXY="http://user:pass@pr.proxynet.io:8000" node check-egress-ip.mjs
```

## Kullanım alanları

- **Pazaryeri entegrasyonu testi:** Test ortamı adres istiyor, ekip dağınık çalışıyor. Ekip tek bir statik adresten çıkar; canlı ortama geçerken servisin o ortam için kuralını yeniden okuyun. E-ticaret tarafındaki diğer senaryolar [e-ticaret proxy](/tr/e-commerce-proxy) sayfamızda.
- **Konuma bağlı API yanıtlarını test etmek:** Aynı uç noktanın farklı ülkelerden nasıl yanıt verdiğini görmek için ülke seçilebilen sabit adresler kullanılır; kurgu [uygulama testi](/tr/app-testing) sayfamızda.
- **Kargo, stok ve tedarikçi API'leri:** Depo, muhasebe ve evden çalışan operasyon ekibi aynı servise gidiyorsa ya hepsi ofis ağına VPN ile bağlanır ya da tek bir statik adresten çıkar.

## IP doğru ama hâlâ hata alıyorsanız

- **Tanım henüz etkin değil.** Adresi bugün bildirdiyseniz servisin işleme süresini bekleyin.
- **Yanlış ortam.** Test ortamına tanımlanan adres canlı ortamda, canlı anahtar da test ortamında geçmez. Alan adını ve anahtar çiftini birlikte kontrol edin.
- **IPv6'dan çıkıyorsunuz.** `api64.ipify.org` IPv6 adresi döndürüyorsa ve servis IPv6 destekliyorsa ya IPv6 adresinizi de bildirin ya da istemciyi IPv4'e zorlayın (`curl -4`).
- **Eksik başlık.** `User-Agent`, `Content-Type` ya da servise özgü bir başlık eksik olduğunda da `403` dönebilir. Dokümandaki örnek isteği birebir çalıştırıp farkı bulun.
- **İstek beklediğiniz makineden çıkmıyor.** Servise sunucunun adresi kayıtlıyken isteği kendi bilgisayarınızdan Postman ile deniyor olabilirsiniz; zamanlanmış görev de başka bir sunucuda çalışıyor olabilir. Betiği isteği atan sürecin yanında çalıştırın.
- **Kabuktaki proxy değişkeni.** `HTTPS_PROXY` tanımlı bir terminalden çalışan araç siz fark etmeden proxy'den çıkar; servis olarak başlatılan uygulama ise kabuktaki değişkeni görmez.

## Karar rehberi

| Durumunuz | Öneri |
|---|---|
| Ödeme, e-fatura, e-defter, sağlık ya da kamu entegrasyonu | Kendi hattınıza statik IP ya da rezerve adresli kendi sunucunuz; proxy kullanmayın |
| Entegrasyon sürekli çalışıyor (stok, sipariş, zamanlanmış görev) | Sabit IP'li VPS ya da bulut sunucu |
| Birden fazla sunucu, konteyner ya da serverless fonksiyon | Bulut NAT gateway ve rezerve adres |
| Kod ofisteki tek bilgisayarda çalışıyor | İnternet sağlayıcınızdan statik IP |
| Test ortamı adres istiyor, ekip evden çalışıyor | Size ayrılmış statik proxy |
| Hat CGNAT arkasında, sağlayıcı statik IP vermiyor, veri hassas değil | Statik proxy ya da küçük bir VPS |
| Hata `403` ama adres doğru | Başlıkları, ortamı ve IPv6'yı kontrol edin |

## Sıkça sorulan sorular

### IP yetkilendirme gerekiyor ne demek?

Servis, isteğinizin geldiği adresi hesabınıza kayıtlı adreslerle karşılaştırmış ve eşleşme bulamamış demektir. API anahtarınız doğru olabilir; sorun isteğin çıktığı adrestedir. Çıkış IP'nizi isteği atan makineden ölçüp kayıtlı adresle karşılaştırın.

### Dinamik IP ile API entegrasyonu yapılır mı?

Servis adres istemiyorsa evet, hiçbir sorun çıkmaz. Adres istiyorsa dinamik hat kalıcı çözüm değildir: adres her değiştiğinde servise yeni bir bildirim yapmanız gerekir ve arada entegrasyon durur. Dört seçenekten biriyle sabit bir çıkış adresi edinin.

### API'ye birden fazla IP adresi tanımlanabilir mi?

Servise göre değişir. Bazıları birden fazla adrese ya da bir adres aralığına izin verir, bazıları tek adresle sınırlar. İki çıkış noktanız varsa (sunucu ve yedeği) başvuruda ikisini birlikte bildirin.

### VPN ile sabit IP elde edilir mi?

Tüketici VPN uygulamalarında hayır: adresler çok sayıda kullanıcıyla paylaşılır ve her bağlantıda değişebilir. Şirketinizin kendi VPN sunucusu ise işe yarar, çünkü o sunucunun çıkış adresi sabittir ve uzaktaki çalışanlar ofis ağı üzerinden çıkar.

### Statik proxy kullanırsam API anahtarımı proxy görür mü?

API'yi `https://` ile çağırıyorsanız hayır. Proxy yalnız bağlanmak istediğiniz sunucunun adını ve portunu görür, ardından şifreli tüneli iletir; anahtarınız ve yanıtlar tünelin içindedir. `http://` ile çağrılan bir API'de ise her şey açık gider; böyle bir API'yi proxy'li ya da proxy'siz kullanmayın.

### Proxy'yi bıraktığımda API'deki IP kaydını ne yapmalıyım?

Aynı gün sildirin. Adres size ayrılmış olsa da hizmet bittikten sonra başka bir müşteriye verilebilir ve servisteki kayıt durdukça o adres hesabınız için izinli kalır. Aynı kural kapattığınız sunucuların rezerve adresleri için de geçerlidir.

## Özet

IP yetkilendirme hatası bir kod hatası değil, adres uyuşmazlığıdır: servis bir adres tanıyor, isteğiniz başka bir adresten çıkıyor. Önce isteği atan makineden çıkış IP'nizi ölçün, sonra adresi sabitleyin. Hassas veri taşıyan entegrasyonlarda bu adres kendi hattınızın statik IP'si, kendi sunucunuz ya da bulut hesabınızdaki NAT gateway olsun; ödeme, sağlık ve e-fatura tarafında araya üçüncü taraf koymayın. Test ortamları, dağınık ekipler ve geçiş dönemleri için size ayrılmış statik bir adres yeterlidir; seçenekleri [proxy hizmetlerimizde](/tr/proxy) bulabilirsiniz.