HTTPS proxy nedir ve HTTP proxy'den farkı ne?

HTTPS proxy, istemci-to-proxy bağlantısını TLS ile sararar; böylece proxy kimlik bilgileriniz ve CONNECT meta verisi şifreli seyahat eder. HTTP proxy bunları düz metin olarak gönderir. Şifreleme yalnızca ilk atlamayı kapsar — proxy-to-target trafiği, hedef sitenin kendisinin HTTPS kullanıp kullanmadığına göre ayrıca yönetilir.

Nodetonet'te HTTPS proxy kullanmak için sertifika yüklemem gerekiyor mu?

Hayır. Nodetonet alt alan adınızda gerçek Let's Encrypt sertifikaları kullanır; dolayısıyla her modern istemci bunlara kutudan çıktığı gibi güvenir. Özel bir CA sertifikası yüklemenize veya --proxy-insecure bayrakları kullanmanıza gerek yoktur. İstemcinizi alt alan adı hostname'ine yönlendirin, çalışır.

SNI nedir ve proxy'ler için neden önemlidir?

SNI (Server Name Indication), şifreli el sıkışması başlamadan önce ClientHello mesajı içinde hedef hostname'i düz metin olarak taşıyan bir TLS uzantısıdır. Proxy edge'leri, müşteri başına benzersiz bir IP gerekmeden gelen TLS bağlantılarını doğru tünele yönlendirmek için bunu kullanır. Her zaman panelin size verdiği hostname'i kullanarak bağlanmalısınız — ham IP bağlantıları SNI taşımaz ve başarısız olur.

HTTPS proxy'lerle sticky oturum kullanabilir miyim?

Evet. Proxy kullanıcı adınıza -session-XXXX ekleyin; o oturum token'ını paylaşan tüm istekler oturum TTL'si boyunca aynı mobil çıkış IP'sine sabitlenir. Bu, HTTP, HTTPS ve SOCKS5 proxy modlarında aynı şekilde çalışır. TTL ve oturum adlandırma ayrıntıları için sticky oturumlar rehberine bakın.

Ham IP adresi kullandığımda HTTPS proxy bağlantım neden başarısız oluyor?

TLS sertifikası, edge IP'si için değil alt alan adı hostname'iniz (örneğin sub42.nodetonet.com) için yayınlanır. Ham IP ile bağlandığınızda TLS ClientHello SNI taşımaz, edge doğru sertifikayı seçemez ve el sıkışması başarısız olur. Her zaman panelin size atadığı alt alan adı hostname'ini kullanın.

HTTPS proxy modu, HTTP'ye kıyasla bağlantımı yavaşlatır mı?

Yalnızca ihmal edilebilir düzeyde ve yalnızca bağlantı kurulumunda. TLS el sıkışması, veri akmadan önce küçük bir gidiş-dönüş ekler, ancak kurulduktan sonra modern donanımda sürekli throughput üzerindeki TLS yükü minimumdur. Uzun ömürlü bağlantılar veya keep-alive yeniden kullanımı için bu yük birçok istekte amortize edilir.

SOCKS5 yerine ne zaman HTTPS proxy kullanmalıyım?

İstemciniz açıkça TLS şifreli bir proxy bağlantısı gerektirdiğinde HTTPS proxy kullanın — bu durum kurumsal SDK'larla, PAC dosyası tabanlı tarayıcı politikalarıyla veya ağ middlebox'larının düz metin proxy trafiğini incelediği ortamlarda yaygındır. HTTP olmayan protokoller, ham TCP/UDP veya istemci sadeliğinin şifreli proxy taşımacılığından daha önemli olduğu durumlarda SOCKS5 kullanın. Tam karşılaştırma için HTTP vs SOCKS5 rehberimizi okuyun.

SNI hostname'i ağ gözlemcisine görünür mü?

Evet. SNI, el sıkışması herhangi bir şeyi şifrelemeden önce TLS ClientHello içinde düz metin olarak gönderilir; dolayısıyla proxy alt alan adınız (örneğin sub42.nodetonet.com) yol üzerindeki pasif bir gözlemciye görünürdür. Bu, TLS 1.2 ve 1.3'ün standart bir özelliğidir. Proxy hostname'ini gizlemek bir gereksinimseyse, bağlantıyı ek bir tünel katmanına sarın.

HTTPS proxy'ler ve SNI routing — TLS edge'de nasıl yaşar

Yeni Proxy formunu açıp protokolü HTTP'den HTTPS'e çevirdiğinizde, arka planda bir dizi şey gerçekleşir: alt alan adınız için bir TLS sertifikası yayınlanır, edge şifreli trafiği hangi tünele yönlendireceğini öğrenir ve istemciniz sertifika uyarısı almadan bağlanabileceği bir proxy alır. Bu rehber her adımı anlatıyor — sertifika yaşam döngüsü, SNI el sıkışması, TLS'in tam olarak nerede sonlandığı ve HTTPS'i düz HTTP veya SOCKS5'e ne zaman tercih etmeniz gerektiği.

Kısaca: HTTPS-protokol proxy'leri, gerçek bir Let's Encrypt sertifikası kullanarak proxy bağlantısını (istemciden edge'e) şifreler. Edge TLS'i sonlandırır, ardından düz HTTP proxy byte'larını güvenli agent kanalı üzerinden eşleştirilmiş mobil cihaza iletir. Hedef site trafiği yine de normal şekilde HTTPS ile uçtan uca şifrelenir — proxy HTTPS katmanı yalnızca kimlik bilgilerinizi ve CONNECT meta verisini korur.

Kabloda "HTTPS proxy" gerçekte ne anlama gelir

Proxy kurulumunda "HTTPS"in üç farklı yerde görünebileceğini birbirine karıştırmak kolaydır. İşte en net döküm:

Atlama	Düz HTTP proxy	HTTPS proxy	SOCKS5 proxy
İstemci → Edge	Düz metin TCP	TLS şifreli TCP	Düz metin TCP (veya sarılmışsa TLS)
Edge → Cihaz (agent kanalı)	Şifreli (WS/TLS)	Şifreli (WS/TLS)	Şifreli (WS/TLS)
Cihaz → Hedef site	Hedefin kullandığı neyse	Hedefin kullandığı neyse	Hedefin kullandığı neyse
Auth header maruziyeti	İlk atlamada düz metin	İlk atlamada şifreli	Kodlanmış ama ilk atlamada hâlâ düz metin

İç edge-to-device kanalı, hangi protokolü seçerseniz seçin her zaman şifrelidir — bu Nodetonet agent'ına yerleşiktir. HTTPS-proxy modu yalnızca istemci-to-edge segmentine TLS ekler. Hedef siteleriniz zaten HTTPS üzerinden sunuluyorsa (ki neredeyse kesinlikle öyledir), HTTPS-proxy modu o trafiğin uçtan uca güvenliğini değiştirmez. Koruduğu şey, makine ile edge arasında başka türlü düz metin olarak seyahat edecek olan Proxy-Authorization başlığı ve CONNECT host:port satırıdır.

Sertifika yaşam döngüsü: form göndermeden ilk isteğe

Her Nodetonet hesabı benzersiz bir alt alan adı alır — örneğin sub42.nodetonet.com. O alt alan adında ilk HTTPS proxy'nizi oluşturduğunuz anda edge, Let's Encrypt ile bir ACME HTTP-01 challenge başlatır. Pratikte bu şu anlama gelir:

Edge, sub42.nodetonet.com için özel bir anahtar ve sertifika imzalama isteği (CSR) oluşturur.
Let's Encrypt sahipliği doğrulamak için edge'deki bilinen bir URL'i çağırır.
Let's Encrypt sertifikayı imzalar (90 gün geçerli) ve edge'e geri döndürür.
Edge sertifikayı TLS dinleyicisine yükler ve bağlantıları kabul etmeye başlar.
30 gün kala yenileme otomatik gerçekleşir — sizden hiçbir işlem gerekmez.

Çok portlu havuzlar — p1.sub42.nodetonet.com'dan p32.sub42.nodetonet.com'a kadar çalıştırdığınız durumlar — DNS-01 challenge ile yayınlanan bir wildcard sertifika (*.sub42.nodetonet.com) kullanır; böylece her alt alan adı tek bir sertifika altında temiz şekilde doğrulanır. Tam hikaye için wildcard SSL sertifikaları nasıl çalışır'a bakın. Nodetonet'e özel bir CNAME yönlendirirseniz (bkz. kendi alan adınızı getirme), edge ilk kullanımda özel hostname'iniz için de sertifika yayınlar.

Yeni oluşturulan bir HTTPS proxy'ye ilk istek, yayın yerleşene kadar ekstra bir-iki saniye sürebilir. Bundan sonra TLS el sıkışmaları edge oturum önbelleğinden geçer ve hızla tamamlanır.

Sertifikayı istediğiniz zaman openssl s_client ile doğrulayabilirsiniz:

openssl s_client -connect sub42.nodetonet.com:48888 -servername sub42.nodetonet.com

CN = sub42.nodetonet.com ve geçerli bir Let's Encrypt zinciri görmelisiniz — --proxy-insecure bayrağına hiç ihtiyacınız olmaz.

SNI routing: edge doğru tüneli nasıl seçer

Edge, az sayıda paylaşılan genel IP ve portta birçok hesap için proxy uç noktaları çalıştırır. Tek bir :443 portu düzinelerce farklı proxy yapılandırmasına ait olabilir. Bir TLS bağlantısı geldiğinde edge, HTTP isteğini bile okumadan önce, bunun hangi kullanıcının tüneline ait olduğunu bilmek zorundadır. Cevap Server Name Indication (SNI)'dir.

SNI, RFC 6066'da tanımlanmış bir TLS uzantısıdır. Her TLS ClientHello mesajı, herhangi bir şifreleme başlamadan önce, el sıkışmasının bir parçası olarak istemcinin ulaşmak istediği hostname'i düz metin olarak taşır. Dizi şöyle görünür:

1.  İstemci, edge IP:443'e (veya özel porta) TCP bağlantısı açar
2.  İstemci, SNI = "sub42.nodetonet.com" ile TLS ClientHello gönderir
3.  Edge SNI alanını okur — şifre çözmeye gerek yok
4.  Edge, o hostname + port için hangi proxy tünelinin kayıtlı olduğuna bakar
5.  Edge eşleşen TLS sertifikasını seçer ve el sıkışmasını tamamlar
6.  TLS edge'de sonlandırılır; bağlantı artık düz HTTP-proxy protokolüdür
7.  Edge Proxy-Authorization başlığını (kullanıcı adı + şifre) doğrular
8.  Edge CONNECT isteğini şifreli agent kanalı üzerinden cihaza iletir
9.  Cihaz hedefe bağlanır ve trafik akar

İki kritik çıkarım:

İstemciler SNI göndermek zorundadır. Her modern istemci gönderir: curl, tüm tarayıcılar, Python'un requests'i, Node'un https modülü, Java, Go, Rust — hepsi varsayılan olarak SNI gönderir. Göndermeyenler gerçekten eskidir (2012 öncesi) ya da yanlış yapılandırılmıştır.
Her zaman hostname kullanın, ham IP kullanmayın. https://1.2.3.4:443'e curl yönlendirirseniz TLS el sıkışması SNI taşımaz, edge tüneli tanımlayamaz ve bağlantı sertifika hatasıyla başarısız olur. Nodetonet panelinin size verdiği tam hostname'i kullanın.

Bağlantı dizisi örnekleri

Format, HTTP ve SOCKS5 ile aynıdır — sadece şemayı https:// ile değiştirin:

# curl (düz HTTPS proxy)
curl -x https://KULLANICIADI:SIFRE@sub42.nodetonet.com:48888 https://api.ipify.org

# curl sticky oturum ile (kullanıcı adına -session-XXXX ekleyin)
curl -x https://KULLANICIADI-session-abc1:SIFRE@sub42.nodetonet.com:48888 https://api.ipify.org

# Python requests
import requests
proxies = {
    "http":  "https://KULLANICIADI:SIFRE@sub42.nodetonet.com:48888",
    "https": "https://KULLANICIADI:SIFRE@sub42.nodetonet.com:48888",
}
r = requests.get("https://api.ipify.org", proxies=proxies)
print(r.text)

# Node.js (https-proxy-agent)
const { HttpsProxyAgent } = require("https-proxy-agent");
const agent = new HttpsProxyAgent("https://KULLANICIADI:SIFRE@sub42.nodetonet.com:48888");
fetch("https://api.ipify.org", { agent });

Geo ve operatör hedefleme için, HTTP proxy'lerde olduğu gibi kullanıcı adına ekler ekleyin — örneğin KULLANICIADI-country-tr-session-abc1. Tam sözdizimi için geo-hedefleme'ye ve oturum sabitleme ayrıntıları için sticky oturumlar açıklandı'ya bakın.

HTTPS proxy vs HTTP proxy vs SOCKS5 — hangisini seçmeli

Senaryo	En iyi seçim	Neden
İstemci düz metin proxy'leri reddediyor (kurumsal SDK, PAC politikası)	HTTPS	TLS, istemcinin güvenlik politikasını ekstra sarmalama olmadan karşılar
Proxy kimlik bilgileri ağ yolunda koklabilir	HTTPS	Proxy-Authorization başlığı istemci-to-edge atlamasında şifreli
Downstream pinning mantığı proxy hostname'iyle eşleşmelidir	HTTPS	Alt alan adınızdaki gerçek LE sertifikası pinning kontrollerini karşılar
Standart web scraping, tarayıcı otomasyonu, API çağrıları	HTTP	Daha basit kurulum, bağlantı sonrası özdeş throughput
Web-dışı trafik (oyun istemcileri, DNS, SSH, özel TCP)	SOCKS5	SOCKS5 ham TCP iletir; HTTP/HTTPS yalnızca HTTP CONNECT'i işler
UDP trafiği (QUIC, oyun, VoIP)	SOCKS5	Yalnızca SOCKS5 UDP datagramlarını taşıyabilir

HTTPS'e özgü nedenler sizin için geçerli değilse, düz HTTP veya SOCKS5 daha basit bir yoldur. Throughput, el sıkışması tamamlandıktan sonra aynıdır — TLS yükü yalnızca bağlantı kurulumuna gecikme ekler, sürekli veri aktarımına değil. İki düz metin seçeneğinin tam karşılaştırması için HTTP vs SOCKS5 — hangisini seçmeli'ye bakın.

HTTPS proxy ve sticky oturumlar

Sticky oturumlar HTTPS proxy üzerinde aynı şekilde çalışır. Kullanıcı adınıza -session-XXXX ekleyin; o oturum token'ını paylaşan tüm istekler, oturum TTL'si boyunca aynı mobil cihaz çıkış IP'sine sabitlenir. Bu, IP'yi oturum ortasında döndürmenin hedef site için hesap ele geçirme gibi görüneceği stateful akışlar — girişler, çok adımlı ödemeler, hesap işlemleri — için doğru moddur. TTL mekaniğini anlamak için sticky oturumlar açıklandı'yı okuyun; hızlı bir tanım için sticky oturum sözlük girdisi'ne bakın.

İstemci başı kontroller: kimlik doğrulama, IP izin listesi ve kotalar

HTTP veya SOCKS5 proxy istemcisinde yapılandırabildiğiniz her şey HTTPS proxy istemcileri için de geçerlidir: kullanıcı adı/şifre doğrulaması, IP izin listesi (proxy'yi hangi kaynak IP'lerin kullanabileceğini kısıtlayın), alan adı izin/reddetme listeleri, bant genişliği kotaları, son kullanma zaman damgaları ve thread (eşzamanlılık) sınırları. Bu kontroller panelde Proxy İstemcileri altında yer alır. Ayrıntılar için proxy istemcileri müşteri başı kimlik doğrulama, IP izin/red listeleri ve istemci başı kota sınırları'na bakın.

HTTPS proxy'nizin doğru IP'yi sunup sunmadığını proxy kontrol aracımızla doğrulayabilir ya da dış siteler tarafından görülen çıkış IP'sini IP adresim nedir aracıyla teyit edebilirsiniz.

Güvenlik değerlendirmeleri

Akılda tutmaya değer birkaç şey:

TLS sonlandırması edge'de, uçtan uca değil. Edge, HTTP CONNECT isteğini okumak için proxy bağlantınızın şifresini çözer. Hedef siteye sonraki tünel, siz (cihaz aracılığıyla) ile hedef arasında ayrı bir TLS oturumudur. Bu standart proxy mimarisidir — herhangi bir kurumsal HTTP-intercept proxy'den farklı değildir.
SNI düz metindir. SNI alanındaki hostname (alt alan adınız), el sıkışması tamamlanmadan önce ağdaki pasif bir gözlemciye görünürdür. Bu, TLS 1.2 ve 1.3'ün temel bir özelliğidir; TLS 1.3'ün Encrypted ClientHello (ECH) standardı henüz yaygın olarak benimsenmemiştir. Proxy hostname'ini gizlemek bir gereksinimseyse, bağlantıyı ek bir tünel katmanına sarmayı değerlendirin.
Proxy-Authorization şifrelidir. Kullanıcı adınız ve şifreniz yalnızca istemci-to-edge atlamasında şifreli metin olarak seyahat eder — güvenilmeyen ağlarda HTTP proxy yerine HTTPS proxy'nin ana pratik avantajı budur.
TCP/IP parmak izi spoofing TLS katmanında değil, cihaz düzeyinde uygulanır. TCP parmak izi spoofing'e güveniyorsanız, proxy-bağlantı protokolünün HTTP mi HTTPS mi olduğundan bağımsız olarak aynı şekilde çalışmaya devam eder.

Sırada ne var

Nodetonet hızlı başlangıç — hesap oluşturmadan ilk isteğe tam platform yürüyüşü.
HTTP vs SOCKS5 — hangisini seçmeli — her düz metin protokolünün ne zaman daha uygun olduğu.
Wildcard SSL sertifikaları — çok portlu havuzlar tek bir sertifikayı nasıl paylaşır.
Kendi alan adınızı getirme — bize bir CNAME yöneltin, onun için bir sertifika yayınlayalım.
Sticky oturumlar açıklandı — stateful akışlar için bir oturumu tek çıkış IP'ye sabitleyin.
Tüm Nodetonet özellikleri — mobil proxy, rotating havuzlar, geo-hedefleme ve daha fazlası.