XRay core açıklandı

İnsanlar XRay'e VPN protokolü demeye devam ediyor. Değil. XRay bir proxy platformu. Onu nginx gibi düşün, ama HTTP isteklerini backend sunuculara yönlendirmek yerine, istediğin protokolü kullanarak şifrelenmiş tunnel'lar üzerinden tüm ağ bağlantılarını yönlendiriyor.

VLESS bir protokol. Reality bir authentication katmanı. WireGuard bir protokol. XRay sunucu tarafında VLESS ve Reality'yi çalıştıran şey. Sansür-direnci ekosisteminin neden böyle çalıştığını anlamak istiyorsan bu ayrımı doğru anlamak önemli.

XRay nereden geldi

Hikaye 2015 civarında "Victoria Raymond" takma adını kullanan biri tarafından yaratılan V2Ray projesiyle başlıyor. V2Ray VMess protokolünü ve transport'ları (TCP, WebSocket, gRPC) proxy protokolünün kendisinden bağımsız değiştirebileceğin modüler bir mimariyi tanıttı. İyi bir fikirdi ve özellikle Çin'de Great Firewall'dan kurtulabilen araçlara ihtiyacı olan insanlar arasında hızla ilgi gördü.

2020'ye kadar V2Ray'in orijinal yaratıcısı sessizleşmişti. V2Fly topluluğu v2fly-core adlı bir fork sürdürdü. RPRX olarak bilinen bir geliştirici, proxy trafiğinin gereksiz TLS şifreleme katmanlarını atlamasına izin veren bir performans optimizasyonu olan XTLS'i katkıda bulundu. Önemli bir teknik katkıydı.

Sonra işler karıştı.

Kasım 2020'de RPRX'in XTLS kodu lisanslama anlaşmazlığı nedeniyle v2ray-core'dan kaldırıldı. Detaylar karmaşık ve biraz politik, ama sonuç temizdi: RPRX v2fly-core'u (commit 9a03cc5'ten) fork'ladı ve xray-core'u yarattı. Temiz bir kopuş.

XRay split'ten sonra daha hızlı ilerledi. RPRX XTLS Vision'ı, sonra Reality'yi, sonra XHTTP'yi gönderdi. Proje şu anda 35.900+ GitHub yıldızı tutuyor, V2Ray'in yaklaşık 22.000'ine karşı. Topluluk commit'leriyle oy verdi. Anti-sansür proxy alanındaki en aktif geliştirme şimdi xray-core'da ya da üzerine inşa edilmiş projelerde oluyor.

XRay gerçekte ne yapıyor

XRay bir Go binary'si. Ona inbound'ları (dinleyiciler) ve outbound'ları (hedefler) tanımlayan bir JSON config besliyorsun ve aralarında trafik proxy'liyor. Tüm model bu.

Güç birleştirebileceklerinde. XRay birden fazla proxy protokolünü destekliyor:

• VLESS, hafif ve şifreleme overhead'i olmayan (bunun için transport katmanına dayanıyor)
• VMess, AES-128-GCM şifrelemeli orijinal V2Ray protokolü (MD5 auth yakın zamanda kaldırıldı)
• Trojan, parola-bazlı auth kullanarak HTTPS trafiğini taklit eden
• Shadowsocks-2022, AEAD-2022 cipher'ları olan modern yeniden yazım

Bunların her biri XRay'in transport'larından herhangi biri üzerinde çalışabilir:

• Ham TCP
• mKCP (UDP-bazlı, KCP gibi ama modifiye edilmiş)
• WebSocket
• HTTP/2 (h2)
• gRPC
• QUIC
• XHTTP (XRay'in kendi multiplexed HTTP transport'u, 2025'te eklendi)

Yani VLESS'i CDN arkasında WebSocket üzerinden çalıştırabilirsin ya da Trojan'ı Cloudflare'dan gRPC üzerinden ya da Reality authentication'lı ham TCP üzerinden VLESS. Protokol ve transport bağımsız. Ağ ortamının izin verdiğine göre karıştır ve eşle.

XRay'in bir routing motoru da var. Belirli domain'ler için trafiği bir outbound üzerinden gönderen, reklamları başka biri üzerinden bloklayan ve geri kalan her şeyi proxy üzerinden yönlendiren kurallar yazabilirsin. Basit bir tunnel'dan çok programlanabilir bir ağ stack'ine yakın.

XTLS ve performans neden önemli

Standart proxy kurulumlarının bir sorunu var. https://example.com'u proxy üzerinden ziyaret ettiğinde, TLS şifrelemesi iki kez oluyor: bir kez tarayıcın ile example.com arasında (iç TLS) ve bir kez client ile proxy sunucu arasında (dış TLS). Zaten şifrelenmiş veriyi şifreliyorsun. Bu israf edilen CPU ve eklenen gecikme.

XTLS Vision bunu düzeltiyor. XRay iç bağlantının zaten TLS 1.3 olduğunu tespit ettiğinde, handshake tamamlandıktan sonra proxy katmanında payload'ı şifrelemeyi durduruyor. İç TLS gizliliği sağlıyor. Dış katman sadece ilk müzakereyi ele almak zorunda.

XTLS splice Linux'ta daha öteye gidiyor. TCP verisini userspace bellek üzerinden kopyalamadan doğrudan file descriptor'lar arasında forward etmek için kernel'in splice() syscall'ını kullanıyor. Veri ağ socket'inden tunnel socket'ine tamamen kernel space'te taşınıyor. XRay'in Go süreci ona zar zor dokunuyor.

Sonuç: doğrudan bağlantıdan birkaç yüzde içinde proxy throughput'u. 1 Gbps link'li bir sunucuda XTLS splice onu doyurabiliyor. Geleneksel çift-şifrelenmiş proxy'ler bunun çok altında doyuyor.

Bu yüzden Reality'li VLESS eski aşma araçlarından çok daha iyi performans gösteriyor. Protokol hafif, transport verimli ve XTLS gereksiz şifreleme vergisini ortadan kaldırıyor.

XRay etrafındaki ekosistem

XRay motor. Etrafında bütün bir araç ekosistemi büyüdü.

3X-UI gibi sunucu yönetim panelleri sana XRay inbound'larını konfigüre etmek, kullanıcı hesaplarını yönetmek ve bandwidth'i izlemek için bir web arayüzü veriyor. Kişisel proxy sunucuları için popülerler çünkü JSON config'leri elle düzenleme ihtiyacını ortadan kaldırıyorlar. Birinin proxy kurulumunun güzel grafikler ve kullanıcı listeleriyle screenshot'ını gördüysen, muhtemelen 3X-UI ya da fork'u.

V2RayN (Windows) ve V2RayA (Linux) gibi masaüstü client'ları xray-core'u GUI ile sarıyor. Abonelik link'lerini okuyorlar, sunucu listelerini yönetiyorlar ve routing kurallarını ele alıyorlar. Sansürlü ülkelerdeki çoğu kullanıcı XRay'le ham binary değil, bu client'lardan biri üzerinden etkileşiyor.

sing-box ilginç olan. SagerNet geliştiricisi tarafından sıfırdan yazılmış daha yeni bir proxy platformu. XRay'in tüm protokollerini (VLESS, VMess, Trojan, Shadowsocks) artı Hysteria2, TUIC ve diğerlerini destekliyor. Daha da önemlisi, gomobile aracılığıyla mobil kütüphaneye derleniyor. VLESS Reality'yi telefonlarda mümkün kılan bu. xray-core'u iOS ya da Android'de makul bir şekilde çalıştıramazsın, ama sing-box'ın libbox'ını yerel bir uygulamaya gömebilirsin.

Ekosistem kabaca şu hatlar boyunca bölünüyor: xray-core sunucularda hâkim, V2RayN/V2RayA masaüstlerinde ve sing-box mobilde. Hepsi aynı protokolleri konuşuyor.

Fexyn XRay'i nasıl kullanıyor

VPN sunucularımızda xray-core çalıştırıyoruz. Her sunucunun port 443'te bir VLESS Reality inbound'u (Reality authentication ile TCP) ve port 8444'te bir XHTTP inbound'u (port 443'e ham TCP'nin filtrelendiği ama HTTP-bazlı transport'ların geçtiği ortamlar için).

Sunucuda Fexyn Agent'ımız xray-core sürecini yönetiyor, anahtar rotasyonunu ele alıyor ve kullanıcı başına UUID'ler tedarik ediyor. VLESS seçili olarak bağlandığında, agent kimlik bilgilerini üretiyor ve client doğru Reality anahtarlarıyla doğru sunucuya işaret eden bir config alıyor.

Client tarafı işlerin ilginçleştiği yer. Windows'ta xray-core'u hiç kullanmıyoruz. Onun yerine, bir Wintun TUN adapter oluşturuyoruz ve tüm sistem trafiğini xray-core'un sağladığı SOCKS5 proxy'ye yönlendirmek için tun2socks çalıştırıyoruz. Aslında, SOCKS proxy modunda strip'lenmiş bir xray-core çalıştırıyoruz ve tun2socks TUN interface'ten paketleri yakalıyor, TCP/UDP oturumlarını yeniden inşa ediyor ve onları o SOCKS proxy üzerinden forward ediyor. İşletim sistemi normal bir ağ adapter'ı görüyor. Tüm trafik onun üzerinden gidiyor. Uygulama-seviyesi proxy konfigürasyonu gerekmiyor.

Android ve iOS'ta sing-box'ı yerel kütüphane olarak derlenmiş halde kullanıyoruz. Aynı VLESS Reality protokolünü ele alıyor ama OS'un VPN framework'ünün (Android'in VpnService'i, iOS'un NEPacketTunnelProvider'ı) içinde çalışıyor. xray-core mobil platformlar için temiz şekilde build olmadığından sing-box buradaki doğru seçimdi ve sing-box'ın libbox'ı tam olarak bu kullanım durumu için tasarlandı.

Sonuç tüm platformlarda aynı: trafiğin microsoft.com'u (ya da Reality config'in hedeflediği herhangi bir SNI) gezen biri gibi görünüyor. DPI sistemleri meşru bir domain'e TLS 1.3 bağlantısı görüyor. Sunucumuza karşı aktif probe'lar gerçek siteye yönlendiriliyor. WireGuard ile protokol karşılaştırması tam olarak buna iniyor: WireGuard daha hızlı ama trivially fingerprint alınabilir, VLESS Reality ise neredeyse tamamen görünmezlik için biraz throughput feda ediyor.

XRay diğer araçlara karşı

Anti-sansür alanında çok proje var. İşte XRay nereye uyuyor.

Shadowsocks orijinaldi. Basit, hızlı, tek-amaçlı şifrelenmiş proxy. 2022 yeniden yazımı (Shadowsocks-2022) eski kriptografik zayıflıkları düzeltti, ama Shadowsocks'un bir tespit sorunu var: GFW paket uzunlukları ve timing'in istatistiksel analizi yoluyla trafik pattern'lerini tanımlayabiliyor. Bazı bölgelerde hâlâ çalışıyor. Ağır sansürlülerde VLESS Reality'den daha az güvenilir.

V2Ray (v2fly-core) XRay'in atası. Hâlâ bakımlı, hâlâ çalışıyor. Ama XTLS Vision, Reality ve XHTTP'si yok. O özelliklere ihtiyacın varsa, ki 2026'da neredeyse kesinlikle var, xray-core'a ihtiyacın var.

Trojan-GFW çıktığında akıllıydı. Proxy trafiğini proxy yanında gerçek bir web sunucusu çalıştırarak HTTPS olarak gizliyor. Reality bu fikri hedef domain için gerçek bir TLS sertifikası sahibi olma ihtiyacını ortadan kaldırarak daha öteye götürdü.

Hysteria 2 obfuscation ile QUIC (UDP-bazlı) kullanıyor. Mükemmel throughput, ama QUIC-bazlı protokoller sansürcülerden daha fazla dikkat alıyor. Bazı ağlar artık QUIC'i tamamen blokluyor ya da throttle ediyor. VLESS Reality gibi TCP-bazlı araçları battaniye-bloklamak daha zor çünkü HTTPS'in kendisini bloklaman gerekirdi.

NaiveProxy Chrome'un network stack'ini gerçek bir Chrome tarayıcısıyla istatistiksel olarak aynı trafiği üretmek için kullanıyor. Tespit etmesi çok zor ama client-tarafı kurulumu daha karmaşık ve panel ve client'lardan oluşan aynı ekosisteme sahip değil.

XRay'in avantajı her alternatiften bir şeyi daha iyi yapması değil. Avantaj bir platform olması. Birden fazla protokol çalıştırıyor, birden fazla transport destekliyor, olgun bir routing motoru var ve en büyük aktif topluluğa sahip. GFW yeni bir tespit yöntemi geliştirdiğinde, xray-core haftalar içinde bir karşı önlem alıyor. 35.000+ yıldız ve bunu silahlanma yarışı olarak ele alan aktif bir bakımcının faydası bu.

Nereye gidiyor

XRay'in geliştirmesi yavaşlamadı. Son sürümler legacy kodunu çıkardı: VMess MD5 authentication gitti, MTProto desteği kaldırıldı. Codebase incelmekte.

İki yaklaşan özellik öne çıkıyor. XDRIVE proxy trafiğini cloud storage işlemleri olarak gizleyen bir transport. XICMP ICMP paketlerini transport katmanı olarak kullanıyor. İkisi de deneysel ama XRay'in evrimini tanımlayan aynı pattern'i temsil ediyorlar: sansürcülerin izin verdiği bir trafik tipi bul ve etrafında bir transport inşa et.

Sürüm şeması projenin hızı hakkında bir şey söylüyor. XRay vYY.M.DD formatını kullanıyor. v26.2.6 sürümü 6 Şubat 2026 anlamına geliyor. Sürümler sık. Proje hızlı hareket ediyor çünkü etmek zorunda. Great Firewall üç aylık release döngüleri beklemiyor.

Sansürlü bir ağda hayatta kalması gereken bir şey inşa ediyorsan, XRay sunucu tarafında çalıştırmak isteyeceğin motor. Tek seçenek değil. Ama en fazla momentum'a, en geniş protokol desteğine ve yeni sansür tekniklerine en hızlı yanıta sahip olan. Bu yüzden Fexyn için onu seçtik.