SSD Nodes Learn Hosting plans →
Rehberler Matt ConnorYazan Matt Connor

HTTP nedir ve sunucu tarafında nasıl çalışır?

HTTP protokolünün temel çalışma prensiplerini, sunucu loglarındaki durum kodlarını, başlık yapılarını ve HTTP/3 ile TLS süreçlerinin yönetimini bu rehberde bulabilirsiniz.

HTTP nedir?

HTTP (hypertext transfer protocol), bir istemci ile web sunucusunun veri talep etmek ve yanıt göndermek için kullandığı kurallar bütünüdür. İstemci bir istek gönderir: GET gibi bir metot, /pricing gibi bir yol, bir protokol sürümü, başlık listesi ve bazen bir gövde. Sunucu, 200 gibi bir durum koduyla ve ardından kendi başlıkları ve genellikle bir gövde ile yanıt verir. Sunucunuzdaki her sayfa görüntüleme ve her API (application programming interface) çağrısı, tekrarlanan bu tek bir alışveriştir.

HTTP kendi durumunu tutmaz. Sunucu, bir saniye önce ne istediğinizi hatırlamaz; bu nedenle oturum açma gibi bellek işlevi gören her şey, her bir istekteki başlık içerisinde taşınır. Bu tek özellik, aşağıdakilerin çoğunu açıklar: önbellekleme tamamen başlık odaklıdır ve bir yük dengeleyici, hiçbir şeyi bozmadan bir sonraki isteğinizi farklı bir arka uç sunucusuna gönderebilir.

Aşağıdaki her şey, bu modelin sunucu tarafında, access log dosyalarınızda ve nginx yapılandırmanızda nasıl göründüğüdür.

Ham bir istek ve yanıt, açıklamalı

Aşağıda eksiksiz bir HTTP/1.1 isteği yer almaktadır. Başlıkları boş bir satır sonlandırır ve bu satırdan sonra gelen her şey gövdedir. Bir GET genellikle gövde içermez.

GET /pricing HTTP/1.1
Host: example.com
User-Agent: curl/8.5.0
Accept: */*
Accept-Encoding: gzip
  • GET, ne yapılmasını istediğinizi belirten metottur. GET okuma yapar, POST veri gönderir, PUT değiştirir, DELETE kaldırır, HEAD ise gövde olmadan bir GET başlıklarını ister.
  • /pricing yoldur. Ana makine adı istek satırının bir parçası değildir, sonraki başlığın var olma nedeni budur.
  • HTTP/1.1, istemcinin kullandığı protokol sürümüdür.
  • Host: example.com, istemcinin istediği sitenin adıdır. HTTP/1.1 bunu zorunlu tutar, bu yüzden nginx bu başlık olmadan gelen isteklere 400 Bad Request ile yanıt verir.
  • Geri kalanlar tercihlerdir. Accept-Encoding: gzip, istemcinin sıkıştırmayı açabileceğini belirtir, böylece sunucunun gövdeyi sıkıştırmasına izin verilir.

Yanıt, en üstte bir durum satırı ile aynı yapıya sahiptir.

HTTP/1.1 200 OK
Date: Thu, 06 Aug 2026 09:12:44 GMT
Server: nginx
Content-Type: text/html; charset=utf-8
Content-Length: 5310
Cache-Control: public, max-age=300

<!doctype html>...
  • 200 OK, neden ifadesiyle birlikte durum kodudur. Önemli olan koddur. İfade bir süslemedir ve istemciler bunu görmezden gelir.
  • Content-Type, istemciye takip eden baytların nasıl işleneceğini söyler.
  • Content-Length, bayt cinsinden gövde boyutudur; böylece istemci gövdenin nerede bittiğini bilir. Boyut önceden bilinmediğinde sunucu bunun yerine Transfer-Encoding: chunked gönderir ve sonu sıfır uzunlukta bir parça ile işaretler.
  • Cache-Control, tarayıcıya ve aradaki tüm önbelleklere bu yanıtı ne kadar süre tutabileceklerini söyler.
  • Başlıklardan sonra gelen boş satır, her iki yönde de başlıkları gövdeden ayırır.

Başlık isimleri büyük/küçük harfe duyarlı değildir ve her satır, yalın bir satır başı yerine satır başı ve satır besleme karakteriyle biter. Bunları elle yazmazsınız ancak paket yakalama işlemlerinde karşılaşırsınız.

Gerçek bir çifti izlemek için, sahip olduğunuz bir site üzerinde şu komutu çalıştırın:

curl -sS -o /dev/null -D - https://example.com/

-D -, yanıt başlıklarını terminalinize yazar ve -o /dev/null gövdeyi atar. Bunu curl -I yerine tercih edin, çünkü -I bir HEAD isteği gönderir. HEAD ile GET arasında farklı işlem yapan bir uygulama sunucusu (ki çoğu öyledir), size hiçbir tarayıcının almayacağı başlıklar gösterecektir. curl -v, > ile işaretlenmiş istek satırları ve < ile işaretlenmiş yanıt satırları ile her iki tarafı da yazdırır.

Nginx erisim logunuzdaki istek satiri nasil görünür

Nginx, combined log formatini kullanir ve tanimi su sekildedir:

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

Bu formatin ürettigi bir satir:

203.0.113.45 - - [06/Aug/2026:09:12:44 +0000] "GET /pricing HTTP/1.1" 200 5310 "https://example.com/" "Mozilla/5.0 (X11; Linux x86_64) Chrome/127.0.0.0 Safari/537.36"
  • 203.0.113.45, TCP (transmission control protocol) baglantisini baslatan adres olan $remote_addr degeridir. Bir proxy arkasinda, asagida aciklanan realip modülünü kullanarak bu degeri degistirmediyseniz, görünen adres ziyaretci degil proxy adresidir.
  • Ilk - sabit bir yer tutucudur. Ikincisi ise yalnizca HTTP temel kimlik dogrulama (basic authentication) kullanimda oldugunda doldurulan $remote_user degeridir.
  • "GET /pricing HTTP/1.1", orijinal istek satirinin tamami olan $request degeridir. Nginx'in varsayilan log kacis (escaping) mekanizmasi ile cift tirnak, ters egik cizgi ve 32'den düsük veya 126'dan yüksek her bayt \xXX seklinde yazilir; bu nedenle satir aslina sadiktir ancak her zaman bayt bazinda birebir ayni olmayabilir.
  • 200, ziyaretcinin algiladigi durum degil, sunucunuzun döndürdügü durum kodudur.
  • 5310, yalnizca gövde boyutunu ifade eden $body_bytes_sent degeridir. Yanit basliklari dahil edilmediginden, bu sayi fiilen gönderilen bayt miktarindan her zaman daha kücüktür.
  • Tirnak icindeki son iki alan Referer ve User-Agent degerleridir. Her ikisi de istemci tarafindan saglandigi icin her türlü veriyi icerebilir.

Gereksiz veriler de kacis karakterleri kullanilarak loglanir. Düz metin 80 numarali portunuza TLS (transport layer security) ile baglanmaya calisan bir istemci, istek alani "\x16\x03\x01\x02\x00\x01" gibi kacirilmis baytlarla baslayan bir 400 satiri birakir. \x16, TLS el sikisma kayit türüdür; dolayisiyla bu baytlar bir istek satiri degil, bir ClientHello baslangicidir. Sunucunuz dogru sekilde davranmaktadir. Bir kaynak, HTTPS istegini HTTP portuna yönlendirmektedir.

Log formatiniza $server_protocol ifadesini de ekleyin. Bu ifade HTTP/1.1, HTTP/2.0 veya HTTP/3.0 degerlerini yazdirir ve bir protokol degisikliginin gercekte devreye girip girmedigini kanitlamanin en hizli yoludur.

Kendi sitenizden dönen yaygın durum kodlarının anlamları

İlk rakam sınıfı belirtir; öncelikle bu sınıfa bakmalısınız.

2xx başarılı olduğunu gösterir. Normal bir okuma için 200 OK. Bir şey oluşturan POST işleminden sonra 201 Created. Genellikle bir DELETE isteğine verilen yanıt olan, geri gönderilecek içerik bulunmadığında başarıyı belirten 204 No Content.

3xx başka bir yere bakılması gerektiğini gösterir. 301 kalıcıdır ve tarayıcılar bunu yoğun biçimde önbelleğe alır; bazen kullanıcı profilini temizleyene kadar bu durum sürer. Bu nedenle yanlış bir ana makine adına yönlendiren bir 301 hatasını düzeltmek zordur. Yönlendirmeyi test ederken 302 kullanın. 304 Not Modified bir hata değil, başarıdır: İstemci koşullu bir istek göndermiştir; ya hala tanıdığınız bir ETag (entity tag) içeren If-None-Match ya da kaynağın değişmediği bir tarih içeren If-Modified-Since ile istekte bulunmuştur. Bu yüzden yanıtı gövdesiz, yalnızca başlıklarla döndürdünüz. Günlük kayıtlarının 304 ile dolu olması önbelleklemenin çalıştığı anlamına gelir.

4xx isteğin hatalı olduğunu gösterir. 400 Bad Request hatalı biçimlendirilmiş girdidir. 401 Unauthorized kimlik doğrulaması yapılmadığı anlamına gelir ve mutlaka şemayı belirten bir WWW-Authenticate başlığı taşımalıdır. 403 Forbidden, isteğin anlaşıldığı ancak yine de reddedildiği anlamına gelir. 404 Not Found mevcut olmayan veya sunucunun varlığını kabul etmek istemediği bir yoldur; bazı uygulamalar erişimi olmayan istemcilerden bir kaynağı gizlemek için 403 yerine 404 yanıtını verir. 405 Method Not Allowed, doğru yola yanlış yöntemle erişilmesidir; statik bir dosya konumuna yapılan POST isteği bunu döndürür. 413, gövdenin nginx'in varsayılan olarak 1 megabayt olan client_max_body_size değerinden büyük olduğu anlamına gelir; hata günlüğü bunu client intended to send too large body ile doğrular.

Statik bir dosyadaki 403 hatası, neredeyse her zaman bir HTTP kuralından ziyade dosya sistemiyle ilgilidir. Herhangi bir yapılandırmayı değiştirmeden önce /var/log/nginx/error.log dosyasını okuyun. open() "/srv/site/index.html" failed (13: Permission denied), nginx çalışan kullanıcısının dosyayı okuyamadığı anlamına gelir; bu durum genellikle üst dizinin diğer kullanıcılar için yürütme iznine sahip olmamasından kaynaklanır. directory index of "/srv/site/" is forbidden, yolun autoindex kapalıyken dizin listeleme dosyası bulunmayan bir dizine çözümlendiği anlamına gelir.

5xx sizin tarafınızda bir sorun olduğunu gösterir. 500 genel sunucu hatasıdır; kendi sitenizde genellikle uygulamanızdaki işlenmemiş bir hataya işaret eder. 502 Bad Gateway, nginx'in yukarı akıştan (upstream) kullanılabilir bir yanıt alamadığı anlamına gelir ve hata günlüğü nedeni belirtir: connect() failed (111: Connection refused) while connecting to upstream, proxy_pass adresinde hiçbir servisin dinleme yapmadığı anlamına gelir. 504 Gateway Timeout, yukarı akışın bağlantıyı kabul ettiği ancak varsayılan olarak 60 saniye olan proxy_read_timeout süresi içinde yanıt vermediği anlamına gelir; günlük bunu upstream timed out (110: Connection timed out) while reading response header from upstream olarak kaydeder. 503 Service Unavailable kasıtlı bir reddetmedir. Nginx'in kendi hız sınırlayıcısının 503 döndürdüğüne dikkat edin; çünkü limit_req_status varsayılan olarak 503 değerindedir. Günlüklerinizde 429 Too Many Requests arıyor ve bunun yerine 503 buluyorsanız nedeni budur. Doğru kodu almak için limit_req_status 429; ayarını yapın.

Sunucuyu çalıştırırken önemli olan başlıklar

Host, siteyi seçer. Tek bir IP adresi yüzlerce ana makine adına hizmet verebilir; nginx, hangi server bloğunun yanıt vereceğine karar vermek için Host ile server_name değerlerini eşleştirir. Hiçbir eşleşme olmazsa, nginx varsayılan sunucuyu kullanır. Bu, başka bir blok default_server olarak işaretlenmediği sürece, ilgili adres ve portu dinleyen ilk bloktur. Yeni bir sanal ana makineden yanlış sitenin gelmesi neredeyse her zaman şundan kaynaklanır: isim eşleşmediği için istek varsayılan bloğa düşmüştür. DNS ayarlarını değiştirmeden şu şekilde test edin:

curl -sS -o /dev/null -D - -H 'Host: app.example.com' http://127.0.0.1/

User-Agent, istemci tarafından yazılan bir öz tanımlamadır ve serbest metindir. Günlük kayıtlarını okurken bunu bir ipucu olarak kullanın. Asla bir kontrol mekanizması olarak kullanmayın; çünkü bu konuda yalan söylemek isteyen bir istemci bunu kolayca yapar. Bu nedenle, bir kazıyıcıyı (scraper) User-Agent ile engellemek yalnızca nazik olanları filtreler.

Content-Type, baytların nasıl yorumlanacağına karar verir: API isteği için application/json, bir sayfa için text/html; charset=utf-8. nginx, dosya uzantılarını /etc/nginx/mime.types ile türlere eşler ve paketlenmiş nginx.conf dosyası default_type application/octet-stream; değerini ayarlar. Bu yüzden nginx'in bilmediği bir uzantıya sahip dosya, tarayıcıda görüntülenmek yerine indirilmesi için sunulur. Görünür belirti, tarayıcı konsolunda Refused to apply style from ... because its MIME type ('text/plain') is not a supported stylesheet MIME type hatası yazarken stil dosyaları yüklenmemiş bir sayfadır. MIME, bu tür dizelerinin geldiği adlandırma şeması olan "multipurpose internet mail extensions" ifadesinin kısaltmasıdır.

Cache-Control, sunucunuz ile okuyucu arasındaki her önbelleği nasıl kontrol edeceğinizi belirler. public, max-age=31536000, immutable, dosya adı içerik özeti (hash) içeren varlıklar için uygundur; çünkü içerik değiştiğinde dosya adı da değişir. no-store, kullanıcıya özel her şey için kullanılmalıdır; çünkü oturum açılmış bir sayfayı tutan paylaşımlı bir önbellek, aynı URL'yi isteyen bir sonraki kişiye bu sayfayı gösterebilir. private orta seviye bir ayardır: tarayıcı dosyayı tutabilir ancak paylaşımlı bir önbellek tutamaz.

X-Forwarded-For, bir proxy ziyaretçiyi gizlediği için gereklidir. Bir istek reverse proxy üzerinden geçtiğinde, $remote_addr proxy'nin adresidir. Bu nedenle, orijinal adresi geri yükleyene kadar günlükleriniz, coğrafi konum verileriniz ve hız sınırlayıcılarınız (rate limiter) tek bir istemci görür. Proxy'nin orijinal adresi iletmesi gerekir:

proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Daha sonra alıcı sunucuya, bu bilgiye güvenmesi ve tam olarak kime güveneceği söylenmelidir:

set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;

Bu iki direktif, nginx'in realip modülüne aittir. $remote_addr değerini iletilen adresle değiştirir ve bağlantının kendi adresini $realip_remote_addr içinde tutar. nginx'i kendiniz derliyorsanız --with-http_realip_module ekleyin, çünkü bu modül varsayılan olarak derlenmez.

Yalnızca kontrol ettiğiniz aralıkları listeleyin. set_real_ip_from 0.0.0.0/0;, herhangi bir istemcinin gönderebileceği düz metin olan X-Forwarded-For değerine dayanır; bu nedenle bir ziyaretçinin, günlüklediğiniz ve hız sınırlayıcınızın saydığı adresi seçmesine izin verir.

X-Forwarded-Proto, belirli ve çok yaygın bir hatayı önler. Proxy'niz TLS sonlandırmasını yapar ve isteği uygulamaya düz HTTP üzerinden iletir. Uygulama düz bir istek görür, ziyaretçinin HTTPS üzerinde olması gerektiğine karar verir ve 301 https://example.com/ yanıtını döner. Tarayıcı bunu takip eder, proxy tekrar TLS sonlandırması yapar ve tekrar düz HTTP iletir; tarayıcı ERR_TOO_MANY_REDIRECTS hatası verene kadar döngü tekrarlanır. X-Forwarded-Proto: https göndermek, uygulamaya ziyaretçinin zaten HTTPS üzerinde olduğunu bildirir, böylece uygulama yönlendirmeyi durdurur.

HTTP/1.1, HTTP/2 ve HTTP/3: sizin için neler değişiyor

HTTP/1.1 metin tabanlıdır ve pratikte bağlantı başına tek bir isteği işler. Connection: keep-alive, bir sonraki isteğin aynı TCP bağlantısını yeniden kullanmasına olanak tanır; bu da kurulum maliyetinden tasarruf sağlar, ancak yanıtlar yine de talep edildikleri sırada gelir. Protokol ayrıca, istemcinin yanıtları beklemeden birden fazla istek yazabildiği pipelining özelliğine de izin verir, ancak sıralama kuralı hala geçerlidir ve hiçbir modern tarayıcı pipelining özelliğini varsayılan olarak açmaz. Yavaş bir yanıt, arkasında kuyruğa alınan her şeyi engeller. Buna head-of-line blocking denir ve tarayıcılar aynı ana bilgisayar adına aynı anda birden fazla bağlantı açarak bu sorunu aşmaya çalışır.

HTTP/2 aynı yöntemleri ve aynı durum kodlarını korur, ancak çerçeveleme yapısını ikili (binary) formata dönüştürür. Birçok istek, bağımsız akışlar olarak tek bir bağlantıyı paylaşır ve tekrarlanan başlık metni sıkıştırılır; modern bir istek çok fazla başlık verisi taşıdığı için bu önemlidir. Bağlantı hala TCP tabanlıdır, bu nedenle kaybolan tek bir paket, yeniden iletim gerçekleşene kadar o bağlantıdaki tüm akışları durdurur. Head-of-line blocking ortadan kalkmamıştır. HTTP katmanından taşıma katmanına taşınmıştır. Server push, HTTP/2'nin bir parçasıydı ancak Chrome'un 2022'de desteği kaldırması nedeniyle pratikte artık kullanılmamaktadır.

HTTP/3 yine aynı anlamsal yapıyı korur ve TCP'yi, UDP (user datagram protocol) üzerine inşa edilmiş bir taşıma protokolü olan QUIC ile değiştirir. QUIC akışları tamamen bağımsızdır, bu nedenle kaybolan bir paket yalnızca ait olduğu akışı durdurur. TLS 1.3, üzerine katman olarak eklenmek yerine QUIC el sıkışmasına dahil edilmiştir, bu nedenle yeni bir bağlantı daha az gidiş-dönüş (round trip) gerektirir. Bunun iki pratik sonucu vardır: UDP 443 numaralı port yol üzerindeki her güvenlik duvarında açık olmalıdır ve UDP trafiğini kısıtlayan veya engelleyen herhangi bir ağ, istemcileri HTTP/2'ye geri dönmeye zorlayacaktır.

Somut olarak sizin için neler değişiyor? Tarayıcılar genellikle HTTP/3 ile başlamaz. HTTP/2 veya HTTP/1.1 üzerinden bağlanırlar, yanıtta bir Alt-Svc: h3=":443"; ma=86400 başlığı görürler ve o ana bilgisayara yapılan sonraki bağlantılar için HTTP/3 kullanırlar. Bunun istisnası, DNS'teki alpn değeri h3 listesini içeren bir HTTPS kaydıdır; bu, Firefox gibi bir tarayıcının ilk bağlantıda HTTP/3 açmasına olanak tanır. Bu kayıt ek bir ipucudur, bir değiştirici değildir; bu nedenle başlık isteğe bağlı bir süsleme değildir. Temel keşif mekanizmasıdır. Nginx'te HTTP/2, 1.25.1 sürümünde kendi yönergesi haline gelmiştir (server bloğu içinde http2 on;, eski listen ... http2 parametresinin yerini almıştır) ve QUIC, 1.25.0 ana sürümüne gelmiştir; burada bir HTTP/3 sitesi, standart listen 443 ssl; ile birlikte listen 443 quic reuseport; gerektirir. HTTP/3 modülü varsayılan olarak derlenmez (--with-http_v3_module) ve Nginx belgeleri hala bu desteği deneysel olarak nitelendirir.

Proxy'ler bu konuda olgunluk açısından farklılık gösterir ve bunu kullandığınız sürümle karşılaştırmanız gerekir. Ekim 2026 itibarıyla Caddy, HTTP/3'ü herhangi bir yapılandırma gerektirmeden varsayılan olarak sunar. Nginx, açık bir quic dinleyicisine ve yukarıda açıklanan Alt-Svc başlığına ihtiyaç duyar. Traefik, bunu açık bir http3 seçeneği aracılığıyla giriş noktası bazında etkinleştirir. TLS termination işlemini birden fazla Docker uygulamasının önünde Traefik ile yapıyorsanız, ziyaretçilerinizin aldığı protokol sürümü orada belirlenir ve proxy'den container'ınıza olan bağlantı, tarayıcının ne üzerinde anlaştığına bakılmaksızın genellikle standart HTTP/1.1'dir.

Varsaymak yerine doğrulayın. curl --http3 -sS -o /dev/null -D - https://example.com/ yalnızca curl -V özellikleri arasında HTTP3 listelenmişse çalışır ve çoğu dağıtım paketi bunu içermez. Güvenilir kontrol kendi günlüğünüzdür: biçime $server_protocol ekleyin ve gerçek tarayıcıların ne üzerinde anlaştığını okuyun. Bunların öncesinde, UDP 443'ün gerçekten açık olduğunu doğrulayın; çünkü yalnızca TCP 443'e izin veren bir güvenlik duvarı, site HTTP/2 üzerinden çalışmaya devam ederken HTTP/3'ün sessizce başarısız olmasına neden olur. Linux sunucunuzda hangi portların açık ve dinlemede olduğunu bilmek, kontrol edilmesi gereken ilk şeydir.

HTTPS: HTTP protokoldür, TLS ise sarmalayıcıdır

HTTPS ayrı bir protokol değildir. TLS oturumu içinde taşınan aynı istekler ve aynı durum kodlarıdır. 80 numaralı port bunları açık metin olarak, 443 numaralı port ise şifreli olarak taşır. TLS el sıkışması önce tamamlanır, ardından HTTP isteği şifreli kanal üzerinden iletilir. Bu sıralama nedeniyle bir sertifika sorunu hiçbir zaman bir durum koduyla ilişkilendirilmez: hata, tek bir HTTP baytı gönderilmeden önce gerçekleştiği için numaralandırılacak bir yanıt yoktur.

Birden fazla site barındıran bir sunucuda bir sıralama detayı önem taşır. Sertifika, herhangi bir HTTP başlığı mevcut olmadan önce ana bilgisayar adını açık metin olarak taşıyan TLS el sıkışmasındaki bir alan olan SNI (server name indication) kullanılarak seçilir. Bu nedenle sunucu önce SNI üzerinden bir sertifika seçer, ardından ikinci adımda Host başlığından bir sanal ana bilgisayar seçer. Bunlar normalde birbiriyle uyumlu olan iki ayrı arama işlemidir. Uyumsuz olduklarında, tarayıcı NET::ERR_CERT_COMMON_NAME_INVALID gibi bir isim uyuşmazlığı hatası gösterir ve hiçbir istek göndermez; çünkü varsayılan sunucunuzun sertifikası, kapsamadığı bir isim için sunulmuştur.

Halka açık bir site için gerçek bir sertifika alın ve otomatik olarak yenilenmesini sağlayın. Certbot with Let's Encrypt on nginx, sertifika yollarını sunucu bloğunuza yazar ve yenileme zamanlayıcısını sizin için kurar. Dahili bir isim veya kendi ağınızdaki çıplak bir IP adresi gibi hiçbir genel otoritenin doğrulayamayacağı bir ana bilgisayar adı için, her istemciye güvenmesi gerektiğinin söylenmesi şartıyla a self-signed certificate on Ubuntu dürüst bir seçenektir.

TLS çalıştığında, 80 numaralı porttaki her şeyi 443 numaralı porta yönlendirin:

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Strict-Transport-Security başlığını yalnızca emin olduğunuzda ekleyin. add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always; başlığı, tarayıcılara o ana bilgisayar adı için düz HTTP'yi iki yıl boyunca reddetmelerini söyler ve tarayıcılar bunu kendi önbelleklerinden uygular; bu da başlığı daha sonra kaldırmanın işlemi geri almayacağı anlamına gelir. Birkaç saatlik bir max-age ile başlayın, her alt alan adının gerçekten HTTPS üzerinde olduğunu doğrulayın ve ardından süreyi artırın.

FAQ

HTTP ve HTTPS arasındaki fark nedir?

HTTPS, bir TLS (transport layer security) oturumu içerisinde gönderilen HTTP'dir. Metotlar ve durum kodları aynıdır. Değişen şey, baytların istemci ile TLS sonlandırıcısının arasında şifrelenmiş olması ve varsayılan portun 80'den 443'e taşınmasıdır. TLS el sıkışması, ilk HTTP baytı gönderilmeden önce tamamlandığı için sertifika hataları hiçbir zaman bir durum kodu üretmez; bu nedenle tarayıcı sertifika uyarısı, 403 gibi bir sayı yerine NET::ERR_CERT_COMMON_NAME_INVALID gibi bir hata adı gösterir.

Sitem neden 502 Bad Gateway hatası veriyor?

Nginx'ten gelen bir 502, nginx'in proxy yaptığı upstream servisinden kullanılabilir bir yanıt alamadığı anlamına gelir; yani ziyaretçinin isteği doğrudur ancak nginx'in arkasındaki bir şey hatalıdır. /var/log/nginx/error.log dosyasını okuyun. connect() failed (111: Connection refused) while connecting to upstream, proxy_pass içindeki adres ve portta hiçbir servisin dinleme yapmadığı anlamına gelir; bu nedenle uygulamanın çalıştığını ve beklediğiniz yere bağlandığını kontrol edin. no live upstreams while connecting to upstream, upstream bloğundaki her sunucunun tekrarlanan hatalardan sonra devre dışı bırakıldığı anlamına gelir. Bağlantıyı kabul edip ardından proxy_read_timeout süresi içinde yanıt veremeyen upstream durumunu belirten 504 Gateway Timeout ile karşılaştırın.

Erişim loglarım neden her ziyaretçi için aynı IP adresini gösteriyor?

Çünkü $remote_addr, TCP bağlantısını açan adresi kaydeder; bir reverse proxy veya içerik dağıtım ağının arkasında bu adres proxy'nin kendisidir. Ziyaretçinin adresi bunun yerine X-Forwarded-For başlığında gelir. Proxy üzerinde proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ayarını yapın, ardından alıcı nginx üzerinde set_real_ip_from değerini proxy'nin adres aralığına ayarlayın ve real_ip_header X-Forwarded-For; kullanın. Yalnızca kontrol ettiğiniz aralıkları listeleyin; çünkü bu başlık herhangi bir istemcinin gönderebileceği bir metindir. Tüm internete güvenmek, ziyaretçinin logladığınız ve hız sınırlaması uyguladığınız adresi seçmesine olanak tanır.

HTTP/2 veya HTTP/3 açmam gerekiyor mu?

HTTP/2'yi açmaya değerdir; çünkü halihazırda TLS kullanan bir sitede tek bir direktif ile etkinleştirilir ve çok sayıda küçük dosya içeren sayfaları yavaşlatan bağlantı başına istek sınırını kaldırır. HTTP/3 daha küçük ve daha belirsiz bir kazanç sağlar; ayrıca açık bir UDP 443 portu ve QUIC desteğiyle derlenmiş bir proxy gerektirir. Tarayıcıların genellikle HTTP/3'e yalnızca daha önceki bir yanıtta bir Alt-Svc başlığı gördüklerinde veya h3 listeleyen bir HTTPS DNS kaydı olduğunda geçiş yaptığını unutmayın; bu nedenle bunlardan biri olmadan listen satırınız ne derse desin hiçbir şey değişmez. Log formatınıza $server_protocol ekleyin ve zaman harcamadan önce ziyaretçilerin gerçekte neyi müzakere ettiğini ölçün.

Dosya mevcut olduğu halde 403 Forbidden ne anlama gelir?

Statik bir sitede 403 genellikle bir HTTP kuralından ziyade dosya sistemi izniyle ilgilidir. /var/log/nginx/error.log içindeki open() ... failed (13: Permission denied), nginx çalışan kullanıcısının dosyayı okuyamadığı anlamına gelir; bu durum genellikle dosya modunun yanlış olmasından ziyade, üst dizinin diğer kullanıcılar için çalıştırma iznine sahip olmamasından kaynaklanır. directory index of ... is forbidden, isteğin dizin listeleme kapalıyken (autoindex) dizin dosyası olmayan bir dizine yönlendirildiği anlamına gelir. Eşleşen location bloğundaki açık bir deny kuralı da 403 döndürür; bu nedenle hata günlüğü hiçbir şey söylemediğinde o bloğu okuyun.

#http#https#web-server#headers#http3