Bu hafta sonu, elimde AWS Free Tier'ın verdiği 6 aylık (181 gün), 200 dolara kadar kredi ve basit bir sorunla oturdum: kendi proxy sunucumu kurmak istiyordum ama datacenter IP'lerin ChatGPT veya Netflix gibi servislerde nasıl engellendiğini de biliyordum. Bu yazı, o sorunu çözene kadar attığım adımları, karşılaştığım gerçek hataları ve onları nasıl çözdüğümü anlatıyor. Her komut, kendi terminalimden aldığım gerçek çıktılarla birlikte. Kurulum, CachyOS (Arch Linux tabanlı) bir istemci üzerinden AWS EC2'ye SSH ile bağlanılarak gerçekleştirildi. Adım 1: AWS EC2 ve SSH Kurulumu İlk adım AWS konsolundan uygun bir sunucu ayağa kaldırmaktı. AWS konsoluna girip EC2 (Elastic Compute Cloud) altında launch instance dedim. Burada direkt olarak bana "getting started walkthroughs" önerdi. Fakat ne yaptığımı bildiğim için "Launch without a walkthrough" seçeneğini seçtim. Evet, burada bizi AWS'nin "Launch an instance" konfigürasyon arayüzü karşıladı. Ben burada bütçe dostu bir çözüm aradığım için, kredi havuzumu az tüketen t3.micro instance tipini seçili bıraktım. İşletim sistemi olarak da Ubuntu 26.04 LTS'i seçtim. İkisi de Free Tier eligible olarak işaretliydi. Daha sonrasında ise login için Key Pair istedi. Burada "yeni bir key pair oluştur" dedim: Burada anahtarımın .pem uzantılı olduğuna dikkat ettim, çünkü SSH bağlantısında bu formatı kullanacaktım. Sonrasında anahtarı bilgisayarıma indirdi. Daha sonrasında ise AWS Network ayarlarında şu Firewall (security groups) kurallarını tanımladım: SSH (Port 22) - My IP HTTP (Port 80) - Anywhere (panel erişimi için, sonradan kapatılacak) HTTPS (Port 443) - Anywhere (V2Ray bağlantısı için) Kısaca konfigürasyonum bu şekildeydi; advanced ayarlara falan gerek yoktu. Sadece AWS'de çalışan, internete açık bir IP'si olan (CGNAT arkasında değil) ve fazla kaynak gerektirmeyen basit bir makine yeterliydi. Bu arada "Launch instance"a basmadan önce gözüme takılan çok güzel bir özellik vardı: Preview Code. Burada, instance hazırlanırken hangi komutların CLI üzerinden çalıştırılacağını gösteriyor. Daha da güzeli, formatı değiştirerek diğer dillerde nasıl kullanılacağını da gösteriyor, örneğin Python SDK için: Otomasyon script'leri yazarken cidden işe yarayacak bir özellik. Şimdi ise launch instance diyelim ve makinemizi AWS tarafından oluşturmaya bırakalım (kısa bir süre): 5 sn falan sürdü. İlk dashboard izlenimi: Benim aşırı fazla bir AWS kullanmışlığım veya bununla ilgili detaylı çalışmalarım yok ama aradığım şeylerin (örneğin IPv4 ve instance state) ve diğer monitoring, security gibi sekmelerin direkt olarak beni karşılaması işimi kolaylaştırdı. İstemciden sunucuya ilk bağlantı denemesi: İndirdiğim anahtarla (Downloads klasöründen) giriş yaptım: ssh -i ~/Downloads/aws-key.pem ubuntu@54.93.233.182 İlk bağlantıda bilinen hostlar listesine ekleme onayı istendi, giriş sorunsuz sağlandı: The authenticity of host '54.93.233.182 (54.93.233.182)' can't be established. ED25519 key fingerprint is: SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Welcome to Ubuntu 26.04 LTS (GNU/Linux 7.0.0-1006-aws x86_64) Evet. Uzak EC2 makinemizin içindeyiz. Artık kuruluma geçebiliriz. Adım 2: 3X-UI Panel Kurulumu ve İlk Engeller Sunucuya girdikten sonra root yetkisi aldım ve 3X-UI (V2Ray/Xray yönetim paneli) kurulum script'ini çalıştırdım: sudo su - bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh) Kurulum sırasında veritabanı olarak SQLite'ı seçtim. Büyük bir veritabanı yöneticisine ihtiyacım yoktu. ═══════════════════════════════════════════ Database Selection ═══════════════════════════════════════════ 1) SQLite (default — recommended for < 500 clients) 2) PostgreSQL (recommended for high client counts / many nodes) Choose [1]: 1 Panel portu özelleştirme sorusuna y yanıtı verip port 80 olarak ayarladım. Would you like to customize the Panel Port settings? (If not, a random port will be applied) [y/n]: y Please set up the panel port: 80 Your Panel Port is: 80 Port set successfully: 80 Username and password updated successfully Base URI path set successfully Kurulumun son aşamasında SSL kurulumu soruldu: ═══════════════════════════════════════════ SSL Certificate Setup (RECOMMENDED) ═══════════════════════════════════════════ SSL is strongly recommended. Skip only if a reverse proxy or SSH tunnel handles TLS for you. Let's Encrypt now supports both domains and IP addresses! Choose SSL certificate setup method: 1. Let's Encrypt for Domain (90-day validity, auto-renews) 2. Let's Encrypt for IP Address (6-day validity, auto-renews) 3. Custom SSL Certificate (Path to existing files) 4. Skip SSL (advanced — behind reverse proxy / SSH tunnel only) Note: Options 1 & 2 require port 80 open. Option 3 requires manual paths. Note: Option 4 serves the panel over plain HTTP — only safe behind nginx/Caddy or an SSH tunnel. Choose an option (default 2 for IP): 4 ⚠ Panel will be installed WITHOUT SSL/TLS. Login credentials and cookies will travel as plain HTTP. Only safe when: • A reverse proxy (nginx, Caddy, Traefik) terminates TLS for you, or • You access the panel exclusively via SSH tunnel SSL'i atladım (4). Ama script, panelin 127.0.0.1'e mi bağlanacağını da sordu: Bind the panel to 127.0.0.1 only? (recommended — forces SSH tunnel / reverse-proxy access) [y/N]: N Burada N seçtim. Nedeni, ilk aşamada paneli tarayıcıdan test etmek istememdi; y deseydim panele sadece SSH tüneli ile erişilebilecekti, bu da ilk hatayı tespit etmeyi zorlaştıracaktı. Karşılaşılan Hata: 404 Not Found Tarayıcıdan http://54.93.233.182 adresine gittiğimde karşılama ekranı yerine 404 Not Found hatası aldım. Gözlem ve Tespit: 3X-UI'nin son sürümleri, güvenlik gereği paneli ana dizine (/) değil, rastgele oluşturulmuş gizli bir yola (webBasePath) kuruyor. Ana IP'ye girince 404 vermesi bir hata değil, bir güvenlik özelliği. Gizli yolu bulmak için terminalden panel ayarlarını sorguladım: x-ui settings Çıktı şu şekilde geldi: [INF] current panel settings as follows: port: 80 webBasePath: /mubjbN3SXSEBOdEhtd/ Tarayıcı adresini http://54.93.233.182/mubjbN3SXSEBOdEhtd/ olarak güncelledim ve panele başarıyla girdim. Ama giriş ekranı geldikten sonra bir sorun vardı. Kurulum yaparken bana kullanıcı adı ve şifre için sorular sormamıştı! Bunun için panel ayarlarını açtım: root@ip-172-31-38-106:~# x-ui The OS release is: ubuntu ╔────────────────────────────────────────────────╗ │ 3X-UI Panel Management Script │ │ 0. Exit Script │ │────────────────────────────────────────────────│ │ 1. Install │ │ 2. Update │ │ 3. Update to Dev Channel (latest commit) │ │ 4. Update Menu │ │ 5. Legacy Version │ │ 6. Uninstall │ │────────────────────────────────────────────────│ │ 7. Reset Username & Password │ │ 8. Reset Web Base Path │ │ 9. Reset Settings │ │ 10. Change Port │ │ 11. View Current Settings │ │────────────────────────────────────────────────│ │ 12. Start │ │ 13. Stop │ │ 14. Restart │ | 15. Restart Xray │ │ 16. Check Status │ │ 17. Logs Management │ │────────────────────────────────────────────────│ │ 18. Enable Autostart │ │ 19. Disable Autostart │ │────────────────────────────────────────────────│ │ 20. SSL Certificate Management │ │ 21. Cloudflare SSL Certificate │ │ 22. IP Limit Management │ │ 23. Firewall Management │ │ 24. SSH Port Forwarding Management │ │ 25. PostgreSQL Management │ │────────────────────────────────────────────────│ │ 26. Enable BBR │ │ 27. Update Geo Files │ │ 28. Speedtest by Ookla │ ╚────────────────────────────────────────────────╝ Panel state: Running Start automatically: Yes xray state: Running Please enter your selection [0-28]: 7 Are you sure to reset the username and password of the panel? [Default n]: y Please set the login username [default is a random username]: ******** Please set the login password [default is a random password]: ******** Do you want to disable currently configured two-factor authentication? (y/n): n Panel login username has been reset to: ******** Panel login password has been reset to: ******** Please use the new login username and password to access the X-UI panel. Also remember them! Restart the panel, Attention: Restarting the panel will also restart xray [Default y]: [INF] x-ui and xray Restarted successfully Press enter to return to the main menu: ╔────────────────────────────────────────────────╗ │ 3X-UI Panel Management Script │ │ 0. Exit Script │ │────────────────────────────────────────────────│ │ 1. Install │ │ 2. Update │ │ 3. Update to Dev Channel (latest commit) │ │ 4. Update Menu │ │ 5. Legacy Version │ │ 6. Uninstall │ │────────────────────────────────────────────────│ │ 7. Reset Username & Password │ │ 8. Reset Web Base Path │ │ 9. Reset Settings │ │ 10. Change Port │ │ 11. View Current Settings │ │────────────────────────────────────────────────│ │ 12. Start │ │ 13. Stop │ │ 14. Restart │ | 15. Restart Xray │ │ 16. Check Status │ │ 17. Logs Management │ │────────────────────────────────────────────────│ │ 18. Enable Autostart │ │ 19. Disable Autostart │ │────────────────────────────────────────────────│ │ 20. SSL Certificate Management │ │ 21. Cloudflare SSL Certificate │ │ 22. IP Limit Management │ │ 23. Firewall Management │ │ 24. SSH Port Forwarding Management │ │ 25. PostgreSQL Management │ │────────────────────────────────────────────────│ │ 26. Enable BBR │ │ 27. Update Geo Files │ │ 28. Speedtest by Ookla │ ╚────────────────────────────────────────────────╝ Panel state: Running Start automatically: Yes xray state: Running Please enter your selection [0-28]: 0 root@ip-172-31-38-106:~# Ve evet, kullanıcı adı ve parolayı sıfırlayarak kendim yeni kullanıcı adı ve parola tanımladım! Ve web arayüzüne giriş yaptığımda beni çok güzel bir arayüz karşıladı: Ve artık VLESS + WebSocket Inbound kurulumuna geçebiliriz! Adım 3: VLESS + WebSocket Inbound Oluşturma Panele girdikten sonra bağlantıları karşılayacak Inbound kuralını oluşturmamız gerekti. GUI'deki sol menüden Inbounds'u açtım: "Add Inbound" ekranında "Stream" sekmesine geçtiğimde "Transmission" kısmı varsayılan olarak RAW (TCP) geliyordu. Arayüzden bunu ws (WebSocket) yapmak ve Host eklemek bazen karmaşık olabiliyor. Gerçek Hata ve Çözüm: GUI üzerinden ayarları değiştirmeye çalıştığımda arayüz bazen değişiklikleri tam yansıtmadı. En kesin ve hatasız yöntemin "Advanced" sekmesinden JSON config'i doğrudan düzenlemek olduğuna karar verdim. Advanced (JSON) Config: { "listen": "", "port": 443, "protocol": "vless", "tag": "in-443-ws", "settings": { "clients": [], "decryption": "none", "encryption": "none" }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls" ] }, "streamSettings": { "network": "ws", "security": "none", "wsSettings": { "path": "/", "headers": { "Host": "hakanismail.info" } } } } Not: security: none seçmemin sebebi, sunucuda henüz SSL sertifikası olmaması. Trafik şifrelenmiş (TLS) bir port üzerinden değil, ham WebSocket (HTTP upgrade) üzerinden taşınacak. Inbound'u kaydettikten sonra "Clients" kısmından bir kullanıcı oluşturdum ve sağlanan bağlantı QR'ı ile Arch Linux üzerindeki v2rayN istemcisinden bağlantı sağladım. vless:// linki ile bağlantı sağlanabilir fakat QR kod daha kolay oldu. QR kodda önemli bir detay var: iki tane QR kodu var. "Subscription Info" QR'ı bağlantı için kullanılmaz. Bağlantı için kullanmamız gereken, "Vless WS (Arch-Linux:443)" etiketli QR. Bağlantıyı ekledikten sonra alttaki anahtarı "Clear system proxy" konumundan "Set system proxy" konumuna çekiyoruz ve bağlantı sağlanıyor. whatismyip.com üzerinden IP'nin Almanya (AWS) olduğunu teyit ettim. Adım 4: Güvenlik (Panelin Dış Dünyaya Kapatılması) Sistem çalışır durumdaydı ama 3X-UI paneli (80 portu) tüm dünyaya açıktı. İnternetteki botlar IP'yi tarayıp paneli kötüye kullanmaya çalışabilir. Çözüm, AWS güvenlik duvarından 80 portunu kapatmak ve panele sadece SSH tüneli ile girmekti. 1. AWS Security Group Kuralını Sildim AWS konsolundan EC2 → seçili sanal makine → Security sekmesi → Security Groups altındaki tek security grup → Inbound rules kısmına gittim. HTTP (Port 80) kuralını listeden sildim. Artık http://54.93.233.182 adresine dışarıdan kimse erişemiyor. 2. SSH Tüneli (Local Port Forwarding) Kurdum Arch Linux terminalinden şu komutu çalıştırdım: ssh -i aws-key.pem -L 8080:127.0.0.1:80 ubuntu@54.93.233.182 Bu komut, yerel makinenin 8080 portunu, SSH bağlantısı üzerinden sunucunun iç ağındaki 127.0.0.1:80 adresine gizlice yönlendirdi. 3. Test SSH tüneli açıkken tarayıcıya şu adresi girdim: http://127.0.0.1:8080/mubjbN3SXSEBOdEhtd/panel/. Panel sorunsuz açıldı. Dış IP üzerinden denediğimde ise bağlantı zaman aşımına uğradı (Timeout). Sunucu güvenliği sağlandı. Adım 5: Cloudflare WARP Entegrasyonu Şu anda IP'm 54.93.233.182 (Amazon). ChatGPT veya Netflix gibi servisler, trafiğin bir veri merkezinden geldiğini anlayıp erişimi reddedebilir. Bu, film izlerken veya agentik iş yaparken can sıkıcı olabiliyor. Bunu aşmak için AWS sunucusunun içine Cloudflare WARP kurdum. WARP, trafiği Cloudflare'in residential IP havuzundan, yani son kullanıcı IP'lerinden çıkarıyor. 1. WARP Kurulumu AWS sunucusuna SSH ile bağlanıp root oldum. Cloudflare deposunu ekledim ve paketi kurdum: curl -fsSL https://pkg.cloudflareclient.com/pubkey.gpg | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg echo "deb [signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflare-client.list apt update && apt install cloudflare-warp -y 2. Kayıt ve Proxy Modu WARP'ı tüm sunucu trafiğini kesmeyecek, sadece yerel bir SOCKS5 proxy (port 40000) olarak çalışacak şekilde ayarladım: warp-cli registration new # (Kullanım şartları kabul edildi: y) warp-cli mode proxy # Success warp-cli connect # Success 3. Test ve Karşılaşılan Garip Çıktı WARP'ın çalışıp çalışmadığını test etmek için standart trace komutunu kullandım: curl https://www.cloudflare.com/cdn-cgi/trace/ İlginç bir şekilde ekrana HTML olarak 404 Not Found düştü. Bu adresin kendisi bozuk değildi; muhtemelen cloudflare.com'un kendi sitesine özgü bir bot koruması ya da redirect davranışıydı, WARP veya AWS IP'siyle doğrudan ilgisi yoktu. Bunun yerine Cloudflare'in tam olarak bu iş için var olan tanılama adresini denedim: curl https://1.1.1.1/cdn-cgi/trace fl=928f31 h=1.1.1.1 ip=54.93.233.182 ts=1788933479.000 visit_scheme=https uag=curl/8.18.0 colo=FRA sliver=050-tier1 http=http/2 loc=DE tls=TLSv1.3 sni=off warp=off gateway=off rbi=off kex=X25519MLKEM768 warp=off görünce şüphelendim, çünkü WARP zaten bağlıydı. Emin olmak için bağlantıyı kesip tekrar bağladım ve her seferinde aynı komutu tekrarladım: root@ip-172-31-38-106:~# warp-cli disconnect Success root@ip-172-31-38-106:~# curl https://1.1.1.1/cdn-cgi/trace ... warp=off root@ip-172-31-38-106:~# warp-cli connect Success root@ip-172-31-38-106:~# warp-cli status Status update: Connected Network: healthy root@ip-172-31-38-106:~# curl https://1.1.1.1/cdn-cgi/trace ... warp=off warp-cli status "Connected" ve "healthy" dese bile çıktı hep warp=off kaldı. Gerçek Durum: WARP'ı proxy moduna aldığım için varsayılan ağ yönlendirmesine hiç müdahale etmiyor. curl gibi düz bir istek WARP'a hiç girmeden direkt AWS ağından çıkıyor; WARP yalnızca açıkça kendisine yönlendirilen (SOCKS5 üzerinden gelen) trafiği görüyor. Bu artık hipotez değil, connect/disconnect döngüsüyle doğrulanmış bir gözlem. Bunu kanıtlamak için, az önceki testle birebir aynı komutu bu kez WARP'ın SOCKS5 portu üzerinden çalıştırdım: curl -x socks5h://127.0.0.1:40000 https://1.1.1.1/cdn-cgi/trace Not: socks5h kullanmak önemli (düz socks5 değil), çünkü h DNS çözümlemesini de proxy üzerinden yaptırıyor. fl=470f261 h=1.1.1.1 ip=104.28.197.9 ts=1788933795.000 visit_scheme=https uag=curl/8.18.0 colo=FRA sliver=010-tier1 http=http/2 loc=DE tls=TLSv1.3 sni=off warp=on gateway=off rbi=off kex=X25519MLKEM768 Fark net: ip artık AWS'e ait 54.93.233.182 değil, Cloudflare'e ait 104.28.197.9; warp alanı da off'tan on'a döndü. WARP'ın çalıştığı, sadece varsayılan yönlendirmeye dahil olmadığı bu şekilde kanıtlandı. 4. 3X-UI Panelinden Yönlendirme (Routing) WARP kuruldu ama V2Ray trafiği hâlâ AWS'in normal internetinden çıkıyordu. 3X-UI panelinden (SSH tüneli ile girdim), Panel Settings → Xray Configuration kısmındaki JSON config'i güncelledim. outbounds dizisine WARP için bir SOCKS çıkışı ekledim: { "tag": "warp", "protocol": "socks", "settings": { "servers": [ { "address": "127.0.0.1", "port": 40000 } ] } } routing → rules kısmına ise tüm trafiği bu WARP'a yönlendirecek kuralı yazdım: { "type": "field", "outboundTag": "warp", "network": "tcp,udp" } Ayarları kaydedip Xray'i yeniden başlattım. 5. Final Testi v2rayN istemcisinden bağlantıyı kesip tekrar bağlandım. whatismyip.com adresine girdim: Yeni IPv4: 104.28.197.14 (Cloudflare) Yeni IPv6: 2a09:bac1:1e20:8::3a2:d (WARP) Merakımdan, WARP'ı devre dışı bırakıp chat.openai.com adresine direkt AWS IP'si üzerinden de gittim. Beklediğimin aksine herhangi bir hata almadan, sorunsuz açıldı; yani ChatGPT bu spesifik AWS IP'sini o an engellemiyordu. Bu da datacenter IP engellerinin ne kadar tutarsız olduğunu gösteriyor: hangi IP'nin hangi serviste ne zaman engelleneceği önceden kestirilemiyor (Netflix gibi bölge kilidine çok daha sıkı yaklaşan servislerde durum farklı olabilir, ama bunu ayrıca test etmedim). WARP'ın buradaki asıl faydası "aktif bir engeli aşmak" değil, IP'nin görünümünü baştan residential seviyeye çekip bu riski azaltmaktı. Kapanış ve Gözlem Bir hafta sonuna sığan bu lab çalışmasında, standart bir VPS'in nasıl güvenli bir proxy sunucusuna dönüştürüleceğini test ettim. Çıkardığım en önemli dersler: GUI bazen istenen network ayarlarını tam yansıtmayabilir; JSON config'i doğrudan düzenlemek çok daha güven verici. Bir servisi (WARP gibi) sistem geneline yaymak yerine local proxy modunda çalıştırıp ana proxy yazılımının (Xray) routing kurallarıyla yönetmek, hata ayıklamayı inanılmaz kolaylaştırıyor. Yönetim panellerini (3X-UI gibi) dış dünyaya açmamak, SSH local forwarding ile erişmek en sağlam sunucu güvenliği yöntemi. Datacenter IP engelleri servise göre çok değişken ve garantili değil; bu testte ChatGPT AWS IP'mi hiç engellemedi. WARP'ın buradaki kazancı "aktif bir engeli aşmak" değil, IP'nin görünümünü residential seviyeye çekip bu riski önceden azaltmaktı.