Linux Proxy Ayarları: Terminal, apt, Docker ve Git

Bir Linux sunucusunda proxy'yi tanımladınız, curl çalışıyor, sonra sudo apt update eski adrese gidiyor, git clone takılıyor ve docker build ağa hiç çıkamıyor. Bu, yanlış bir ayar yaptığınız anlamına gelmez. Linux'ta merkezi bir "proxy anahtarı" yoktur: kabuğunuzun ortam değişkenleri bir katmandır, her aracın kendi yapılandırma dosyası ikinci katmandır, systemd altında çalışan servisler ise üçüncü ve tamamen ayrı bir katmandır.

Bu yazı o üç katmanı sırayla anlatıyor. Önce geçici ve kalıcı ortam değişkeni ayarını, büyük ve küçük harf farkını, no_proxy yazım kurallarını ve sudo'nun ortamı neden taşımadığını ele alıyoruz. Ardından apt, git, pip, npm ve Docker için ayrı ayrı yapılandırmayı, masaüstü arayüzündeki ayarın terminali neden etkilemediğini, doğrulama adımlarını ve her ayarın geri alma satırını veriyoruz.

Linux'ta proxy ayarı neden tek yerden yapılmaz?#

Windows ve macOS'ta işletim sisteminin bir sistem proxy kaydı vardır ve çoğu program onu okur. Linux'ta böyle bir kayıt yoktur. Onun yerine 1990'lardan kalma bir gelenek vardır: program, çalışırken http_proxy, https_proxy, all_proxy ve no_proxy adlı ortam değişkenlerine bakar, varsa kullanır. Bu bir standart değil, yaygın bir alışkanlıktır. Hangi aracın ona uyduğunu tek tek bilmeniz gerekir.

Üç katmanı ayırt etmek sorunların çoğunu çözer:

1. Kabuk ortamı. export ile tanımladığınız değişkenler, o kabuktan başlattığınız süreçlere miras kalır. Terminali kapatınca biter.
2. Aracın kendi yapılandırması. apt, git, pip, npm ve Docker'ın kendi dosyaları vardır. Bu dosyalar ortam değişkenlerinden bağımsız çalışır ve genellikle onları geçersiz kılar.
3. Servis ortamı. systemd ile başlayan bir servis, sizin kabuğunuzdan doğmadığı için sizin değişkenlerinizi hiç görmez. Kendi birim dosyasından okur.

Bir ayarın neden "çalışmadığını" anlamak için önce o aracın hangi katmana baktığını sormak gerekir.

Proxy adresi hangi biçimde yazılır?#

Aşağıdaki bütün yöntemlerde adres aynı biçimde yazılır:

http://user:pass@pr.proxynet.io:8000

http:// şeması proxy ile kurulan bağlantının protokolüdür ve HTTPS adreslere giderken de aynen kalır. user:pass@ bölümü yalnızca kullanıcı adı ve parolayla doğrulama yapıyorsanız gerekir; panelden sunucunuzun IP'sini yetkilendirdiyseniz bu bölümü tamamen atarsınız. İki yöntemin farkını Proxy Kimlik Doğrulama: User:Pass ve IP Whitelist yazımızda anlattık.

Parolada @, :, # veya / varsa bunları adresin içine yüzde kodlamasıyla yazın: @ için %40, # için %23. Kodlanmamış bir @, adresi yanlış yerden böler ve sonuç genellikle bir 407 Proxy Authentication Required olur. Kodlama ayrıntıları ve kütüphanelerin bu konudaki farkları Node.js'te Proxy Kullanımı yazımızın kimlik bilgileri bölümünde.

Ortam değişkenleriyle geçici ayar#

En hızlı yol, değişkenleri o oturum için tanımlamaktır:

export http_proxy="http://user:pass@pr.proxynet.io:8000"
export https_proxy="$http_proxy"
export no_proxy="localhost,127.0.0.1,.sirketiniz.local"

curl -s https://api.ipify.org; echo

Çıktı sizin değil proxy'nin IP adresini gösteriyorsa ayar çalışıyor demektir. Değişkeni kaldırmak için unset http_proxy https_proxy no_proxy yazmanız yeterlidir.

Bu değişkenlerin ne olduğunu, hangi araçların okuduğunu ve .wgetrc gibi araç dosyalarıyla ilişkisini wget ile Proxy Kullanımı yazımızda ayrıntılı anlattık; burada tekrar etmiyoruz. cURL tarafındaki seçenekler ve SOCKS5 kullanımı için cURL ile Proxy Nasıl Kullanılır? yazımıza bakabilirsiniz.

İki pratik not: export yazmazsanız değişken yalnızca kabuğun kendisinde kalır, çalıştırdığınız programlara geçmez. Tek bir komut için geçici ayar isterseniz değişkeni komutun önüne yazın, o zaman yalnızca o komut etkilenir:

https_proxy="http://user:pass@pr.proxynet.io:8000" curl -s https://api.ipify.org

http_proxy ve HTTP_PROXY: büyük harf neden önemli?#

Linux'ta ortam değişkeni adları büyük harfe duyarlıdır: http_proxy ile HTTP_PROXY iki ayrı değişkendir. Araçlar bu ikisine aynı şekilde davranmaz.

cURL ve libcurl kullanan her şey, proxy değişkenlerinin hem küçük hem büyük harfli yazımını kabul eder, küçük harfli olana öncelik verir. Tek istisna http_proxy'dir: cURL onu yalnızca küçük harfle okur. Nedeni güvenliktir. Bir CGI betiği çalıştığında sunucu, gelen isteğin başlıklarını HTTP_ önekiyle ortam değişkenine çevirir; yani uzaktan gönderilen Proxy: başlığı HTTP_PROXY değişkenini doldurabilir. Bu davranışın geçmişte yol açtığı güvenlik sorunları cURL belgelerinde anlatılıyor.

Pratikte iki kural işinizi görür:

• Küçük harfi esas alın. http_proxy, https_proxy, no_proxy yazın.
• İkisini birden tanımlayın. Bazı Java ve Go araçları yalnızca büyük harfli yazımı arar. İki grubu aynı değere ayarlamak en az sürpriz üreten yoldur.

export http_proxy="http://user:pass@pr.proxynet.io:8000"
export https_proxy="$http_proxy"
export no_proxy="localhost,127.0.0.1"
# buyuk harfli ikizleri de tanimla
export HTTP_PROXY="$http_proxy" HTTPS_PROXY="$https_proxy" NO_PROXY="$no_proxy"

all_proxy ise protokolden bağımsız varsayılandır; protokole özgü bir değişken varsa o öne geçer. SOCKS5 kullanacaksanız all_proxy="socks5h://user:pass@pr.proxynet.io:1080" biçimini tercih edin. socks5h şemasında alan adı çözümlemesi proxy tarafında yapılır. Farkları SOCKS5 Proxy sayfamızda ve SOCKS ve HTTP Proxy Farkı yazımızda bulabilirsiniz.

no_proxy nasıl yazılır?#

no_proxy, proxy'den geçmemesi gereken adreslerin virgülle ayrılmış listesidir. Bir standardı yoktur, bu yüzden araçlar arasında küçük farklar görürsünüz. cURL 8.21 ile yaptığımız denemelerde davranış şöyle:

İki tuzak var. Birincisi port yazımıdır: no_proxy bir ana makine listesidir, sunucu:port yazarsanız o satır hiçbir şeyle eşleşmez ve istek sessizce proxy'ye gider. İkincisi CIDR'in her yerde çalışmadığıdır; Python'un urllib modülü aynı listede 10.0.0.0/8 girdisini tanımaz ve 10.1.2.3 adresini proxy'ye yollar. Python tarafında iç ağı dışarıda tutmak istiyorsanız adresleri tek tek ya da alan adıyla yazın.

Listeye en azından şunları koyun: localhost, 127.0.0.1, varsa iç ağ alan adınız ve konteyner ağı. Aksi halde yerel geliştirme sunucunuza giden istek de proxy üzerinden dolaşır ve zaman aşımına uğrar.

Ayarı kalıcı yapmak: ~/.bashrc ve /etc/environment#

Terminali kapattığınızda export satırları kaybolur. Kalıcılık için iki yer vardır ve kapsamları farklıdır.

Tek kullanıcı için ~/.bashrc. Dosyanın sonuna aynı export satırlarını ekleyin, sonra source ~/.bashrc ile yeniden okutun. Bu dosya etkileşimli kabuklarda çalışır, yani SSH ile girip komut yazdığınızda geçerlidir. Zsh kullanıyorsanız karşılığı ~/.zshrc olur ve satırlar aynen geçerlidir; fish kullanıyorsanız dosya ~/.config/fish/config.fish olur ve yazım set -gx http_proxy "…" biçimine döner.

Sistem geneli için /etc/environment. Bu dosyayı kabuk değil, PAM'in pam_env modülü okur. Oturum açan her kullanıcı için değişkenler tanımlanır. Biçimi katıdır: satır başına bir ANAHTAR=DEĞER, export anahtar sözcüğü belgelerde yazdığı gibi uyumluluk için kabul edilir ama yok sayılır, kabuk genişletmesi yapılmaz. Yani $http_proxy gibi bir başvuru burada çalışmaz, değeri açıkça yazmanız gerekir:

# /etc/environment icerigi, tirnaksiz ve duz
http_proxy=http://user:pass@pr.proxynet.io:8000
https_proxy=http://user:pass@pr.proxynet.io:8000
no_proxy=localhost,127.0.0.1

Değişiklik yeni oturumlarda geçerli olur; açık olan SSH oturumunuzda görmek için çıkıp yeniden girin. Geri almak için satırları silip oturumu yenilemek yeterlidir.

Her iki dosyada da parola düz metin durur. Sunucuda birden fazla kullanıcı varsa /etc/environment yerine kullanıcı dosyasını tercih edin, ya da panelden sunucunun IP'sini yetkilendirip parolasız kullanıma geçin. Sabit çıkış adresi gerektiren bu senaryo için ISP Proxy ve Datacenter Proxy paketleri uygundur.

sudo neden proxy ayarınızı görmez?#

sudo apt update komutu proxy'yi yok sayıyorsa sebep genellikle şudur: sudo, güvenlik gerekçesiyle çağıran kullanıcının ortam değişkenlerinin çoğunu temiz bir ortamla değiştirir. Kullanıcının ortamını korumak istediğinizi -E seçeneğiyle bildirirsiniz; sudo kılavuzunda belirtildiği gibi güvenlik politikası bu isteği reddedebilir.

sudo -E apt update

Komut hâlâ proxy'yi kullanmıyorsa iki olasılık kalır: ya sudoers yapılandırması bu değişkenlerin geçişine izin vermiyordur, ya da araç zaten ortam değişkenine değil kendi dosyasına bakıyordur. apt için ikincisi daha sağlam bir çözümdür ve bir sonraki bölümün konusu.

apt proxy ayarı#

apt, ortam değişkenlerini de okur ama asıl yeri /etc/apt/apt.conf.d/ dizinidir. Buraya bırakacağınız bir parça dosya, hem sudo sorununu hem de cron ile çalışan güncellemeleri çözer.

// /etc/apt/apt.conf.d/95proxy
Acquire::http::Proxy "http://user:pass@pr.proxynet.io:8000";
Acquire::https::Proxy "http://user:pass@pr.proxynet.io:8000";

Satır sonundaki noktalı virgül zorunludur. Belirli bir sunucuyu proxy dışında tutmak için o ana makineye özgü satırı DIRECT anahtar sözcüğüyle yazarsınız:

Acquire::http::Proxy::depo.sirketiniz.local "DIRECT";

Dosya adında dikkat edilecek bir nokta var: apt.conf kılavuzuna göre bu dizindeki parçalardan yalnızca uzantısı olmayan ya da uzantısı conf olan, adında da yalnızca harf, rakam, tire, alt çizgi ve nokta bulunanlar okunur. Yani 95proxy ve 95proxy.conf geçerlidir; 95proxy.bak yok sayılır ve apt bunu bir bildirimle söyler. Ayarı geri almak için dosyayı silin ya da dizin dışına taşıyın, ek bir komut gerekmez.

git proxy ayarı#

git, HTTP ve HTTPS adresleri için libcurl kullanır, dolayısıyla http_proxy ve https_proxy değişkenlerini zaten okur. Kalıcı ve açık bir ayar istiyorsanız kendi yapılandırmasına yazın:

git config --global http.proxy "http://user:pass@pr.proxynet.io:8000"

git config --global --get http.proxy      # dogrula
git config --global --unset http.proxy    # geri al

Yalnızca belirli bir sunucu için geçerli olsun isterseniz adrese göre koşullayabilirsiniz. Bu, iç ağdaki git sunucunuza doğrudan, dışarıya proxy ile gitmenizi sağlar:

git config --global http.https://github.com.proxy "http://user:pass@pr.proxynet.io:8000"

Denememizde ortaya çıkan bir ayrıntı pratikte sık sorun çıkarıyor. git'in http.proxyAuthMethod ayarının varsayılanı anyauth'tur ve git-config belgesine göre bu mod, proxy'nin kimliksiz isteğe 407 ve Proxy-Authenticate başlığıyla yanıt vermesini bekler. Bu keşif turunu tamamlayamayan proxy'lerde git Proxy CONNECT aborted hatası verip durur. Aynı komut basic ile ilk denemede geçer:

git config --global http.proxyAuthMethod basic

Tek bir komut için ayarı denemek isterseniz -c bayrağı yapılandırmaya hiç dokunmaz: git -c http.proxy=... ls-remote <adres>. SSH ile çekim yapıyorsanız bu ayarların hiçbiri etkili olmaz; SSH için ~/.ssh/config içindeki ProxyCommand satırı gerekir.

pip proxy ayarı#

pip'in üç yolu vardır ve öncelik sırası pip belgelerinde yazılı: komut satırı seçenekleri ortam değişkenlerini, onlar da yapılandırma dosyasını geçersiz kılar.

# 1) tek seferlik
pip install --proxy "http://user:pass@pr.proxynet.io:8000" requests

# 2) ortam degiskeni; PIP_<SECENEK> kalibi her secenek icin gecerli
export PIP_PROXY="http://user:pass@pr.proxynet.io:8000"

Kalıcı ayar için ~/.config/pip/pip.conf dosyasını kullanın. Sistem geneli için /etc/pip.conf, yalnızca bir sanal ortam için $VIRTUAL_ENV/pip.conf aynı biçimi kabul eder:

[global]
proxy = http://user:pass@pr.proxynet.io:8000

Hangi dosyanın okunduğundan emin değilseniz pip config debug bütün yolları ve o an geçerli değerleri sıralar. Geri almak için pip config unset global.proxy yazın ya da satırı dosyadan silin.

npm proxy ayarı#

npm, .npmrc dosyalarını proje, kullanıcı, global ve yerleşik sırasıyla okur; öndeki geridekini geçersiz kılar. npm belgelerine göre HTTP_PROXY ve HTTPS_PROXY ortam değişkenleri de onurlandırılır, noproxy seçeneğinin varsayılanı ise NO_PROXY değişkenidir.

npm config set proxy "http://user:pass@pr.proxynet.io:8000"
npm config set https-proxy "http://user:pass@pr.proxynet.io:8000"
npm config set noproxy "localhost,127.0.0.1,registry.sirketiniz.local"

npm config delete proxy && npm config delete https-proxy   # geri al

Ayarı yalnızca tek bir depoda geçerli kılmak için komutlara --location=project ekleyin; npm o zaman değerleri projenin kök dizinindeki .npmrc dosyasına yazar. Bu dosyayı sürüm kontrolüne göndermeyin, içinde parola vardır.

Küçük bir sürpriz: npm config get https-proxy komutu değeri göstermez, "protected" uyarısı verir. Kimlik bilgisi içeren seçenekler okunmaya kapalıdır. Değeri görmek için .npmrc dosyasını doğrudan açın.

Docker proxy ayarı#

Docker'da tek bir ayar yoktur: arka plan süreci ile konteynerler ayarı birbirinden bağımsız iki yerden okur, üstüne bir de klasik adres tuzağı vardır. Karışıklığın çoğu bundan çıkar.

1. Arka plan süreci (imaj indirme). docker pull ve docker push işlemlerini dockerd yapar, sizin kabuğunuz değil. Docker belgesine göre ayar /etc/docker/daemon.json dosyasındaki proxies anahtarına yazılır:

{
  "proxies": {
    "http-proxy": "http://user:pass@pr.proxynet.io:8000",
    "https-proxy": "http://user:pass@pr.proxynet.io:8000",
    "no-proxy": "localhost,127.0.0.1,.sirketiniz.local"
  }
}

Aynı iş systemd tarafında bir parça dosyayla da yapılır. /etc/systemd/system/docker.service.d/http-proxy.conf dosyasına şu satırlar yazılır:

[Service]
Environment="HTTP_PROXY=http://user:pass@pr.proxynet.io:8000"
Environment="HTTPS_PROXY=http://user:pass@pr.proxynet.io:8000"
Environment="NO_PROXY=localhost,127.0.0.1,.sirketiniz.local"

Her iki yöntemde de ayar sudo systemctl daemon-reload ve sudo systemctl restart docker komutlarından sonra geçerli olur. Bu kalıp yalnızca Docker'a özgü değildir: systemd ile çalışan her servise proxy böyle tanıtılır, çünkü servis sizin kabuğunuzdan doğmaz ve ~/.bashrc dosyanızı hiç okumaz.

2. Konteynerler ve derlemeler. Konteyner içindeki uygulamanın dışarı çıkması ayrı bir konudur. Docker CLI, kendi belgesinde anlatıldığı gibi ~/.docker/config.json dosyasındaki proxies.default bloğunu okur ve oradaki değerleri yeni konteynerlere ve derlemelere ortam değişkeni olarak geçirir:

{
  "proxies": {
    "default": {
      "httpProxy": "http://user:pass@pr.proxynet.io:8000",
      "httpsProxy": "http://user:pass@pr.proxynet.io:8000",
      "noProxy": "localhost,127.0.0.1"
    }
  }
}

Bu dosyanın ayarları arka plan sürecini etkilemez; yalnızca konteyner ve derleme ortamına geçer ve yalnızca yeni oluşturulanlara uygulanır. Tek seferlik kullanım için docker run --env HTTP_PROXY=... ve docker build --build-arg HTTP_PROXY=... aynı işi yapar.

3. Adres tuzağı. Proxy makinenin kendisinde çalışıyorsa konteyner içine http://127.0.0.1:8000 yazmayın. Konteynerin kendi ağ alanı vardır, oradaki 127.0.0.1 konteynerin kendisidir. Ana makineye ulaşmak için ana makinenin ağ adresini kullanın.

Masaüstündeki ayar terminali neden etkilemez?#

Ubuntu'da Ayarlar > Ağ > Ağ Proxy bölümünden yaptığınız tanım GNOME'un kendi ayar deposuna yazılır ve bu değerleri okuyan uygulamaları etkiler: GNOME'un tarayıcısı, yazılım merkezi, masaüstü uygulamalarının çoğu. Terminalde açtığınız kabuk bu depoyu okumaz, dolayısıyla curl ve git etkilenmez. Aynı ayarı komut satırından yapmak isterseniz gsettings set org.gnome.system.proxy mode 'manual' ve ilgili host ile port anahtarları kullanılır, ama terminal tarafı için yine ortam değişkeni gerekir.

Pratik sonuç şu: sunucuda masaüstü yoksa bu bölümü tamamen atlayın. Masaüstünde çalışıyorsanız iki ayarı birden yapmanız gerekir. Diğer işletim sistemlerindeki karşılıkları için Windows'ta Proxy Ayarları, Mac ve Safari'de Proxy Ayarları ve Android'de Proxy Ayarları yazılarımıza bakabilirsiniz.

Araç, dosya ve geri alma tablosu#

Ayarın çalıştığını nasıl doğrularsınız?#

Dört adım, sırayla:

1. Değişkenleri görün. env | grep -i proxy çıktısı beklediğiniz değerleri ve büyük harfli ikizlerini göstermeli.
2. Çıkış adresini görün. curl -s https://api.ipify.org komutunun döndürdüğü adres proxy'nin adresi olmalı.
3. Bağlantıyı izleyin. curl -v çıktısında Uses proxy env variable satırını ve hedef yerine proxy adresine yapılan Trying satırını arayın. Bu iki satır yoksa istek proxy'ye hiç gitmiyordur.
4. Aracı ayrı deneyin. sudo apt update, git ls-remote <adres>, pip download --no-deps six, npm view express version komutları kendi yapılandırmalarını kullanır ve her biri ayrı ayrı doğrulanmalıdır.

Ölçüm ve konum doğrulaması için ayrıntılı adımları Proxy Nasıl Test Edilir? yazımızda topladık.

Sık yapılan hatalar#

• export unutmak. http_proxy=... tek başına değişkeni yalnızca kabukta bırakır, çalıştırdığınız programa geçirmez.
• Yalnızca http_proxy tanımlamak. HTTPS adreslere giden istekler https_proxy değişkenine bakar; eksikse doğrudan çıkmaya çalışır.
• https_proxy değerini https:// ile başlatmak. Proxy'niz TLS sonlandırmıyorsa değer http:// ile başlar.
• Parolayı kodlamadan yazmak. İçindeki @ adresi böler, sonuç 407 olur. 407'nin diğer nedenlerini Scraping'de HTTP Hata Kodları yazımızda sıraladık.
• no_proxy listesine port yazmak. sunucu:8080 girdisi hiçbir şeyle eşleşmez.
• Servisi kabuk ayarıyla beklemek. systemd servisi ~/.bashrc okumaz; birim dosyası ya da parça dosya gerekir.
• Yapılandırma dosyasını unutup ortam değişkenini suçlamak. git config --get http.proxy, pip config debug ve npm config list eski bir değeri ortaya çıkarır.
• Konteyner içinde 127.0.0.1 yazmak. Konteynerin kendi ağ alanı vardır.

Bağlantının hiç kurulmadığı durumların teşhisini Proxy Sunucusu Yanıt Vermiyor Hatası yazımızda ayrı ayrı ele aldık.

Karar rehberi#

Sıkça sorulan sorular#

Ayarları yaptım ama bazı programlar hâlâ doğrudan çıkıyor, neden?#

Ortam değişkenlerini okumak bir zorunluluk değil, alışkanlıktır. Go ile yazılmış bazı araçlar yalnızca büyük harfli yazımı, bazı Java uygulamaları ise kendi -Dhttp.proxyHost parametresini bekler. Programın belgelerinde proxy başlığına bakın; kendi ayarı varsa ortam değişkeni onu geçmez.

Parolayı dosyaya yazmadan proxy kullanabilir miyim?#

Evet. Proxy panelinden sunucunuzun çıkış IP adresini yetkilendirirseniz adres http://pr.proxynet.io:8000 biçimine iner ve hiçbir dosyada parola durmaz. Sabit IP'li sunucularda en temiz yol budur.

Aynı anda birden fazla proxy kullanabilir miyim?#

Ortam değişkenleri tek adres tutar. Ayrımı protokole göre (http_proxy ve https_proxy farklı) ya da araca göre (git'te http.<adres>.proxy, apt'ta ana makineye özgü satır) yaparsınız. İstek başına farklı çıkış adresi gerekiyorsa tek adresli bir Rotating Proxy paketi bu işi sizin yerinize yapar.

SSH bağlantılarım da proxy'den geçer mi?#

Hayır. http_proxy ve arkadaşları SSH istemcisini etkilemez. SSH'i bir proxy üzerinden geçirmek için ~/.ssh/config dosyasında ProxyCommand satırı tanımlanır. git clone git@... biçimindeki adresler de bu yüzden http.proxy ayarını yok sayar.

Cron işlerim proxy'yi neden görmüyor?#

cron, işleri sizin giriş kabuğunuzdan başlatmaz ve ~/.bashrc dosyanızı okumaz. Değişkenleri ya crontab dosyasının başında tanımlayın ya da betiğin ilk satırlarında export ile ayarlayın.

Proxy üzerinden apt yavaşladı, normal mi?#

Paket depoları coğrafi olarak dağıtılmıştır ve proxy trafiği başka bir ülkeye taşıyabilir. Yalnızca dış kaynaklar için proxy kullanıp yerel depo aynalarını Acquire::http::Proxy::<host> "DIRECT"; satırıyla dışarıda bırakmak çoğu durumda yeterlidir.

Özetle#

Linux'ta proxy ayarı üç katmandan oluşur: kabuk ortamı, aracın kendi yapılandırma dosyası ve servis birimi. Terminalde export ile başlayın, kalıcılık için ~/.bashrc ya da /etc/environment kullanın, ardından apt, git, pip, npm ve Docker'ı kendi dosyalarından ayrı ayrı ayarlayın. Her adımda curl -s https://api.ipify.org ile doğrulayın ve no_proxy listesine iç ağınızı eklemeyi atlamayın. Sunucuda çalışacak sabit ve yüksek hacimli işler için veri kazıma çözümlerimize ya da doğrudan HTTPS Proxy sayfamıza göz atabilirsiniz.