Hosting Hesabınızdaki `www` ve `public_html` Dizini Nedir?

`public_html` dizini, web sitenizin belge köküdur — bir ziyaretçi alan adınızı yüklediğinde web sunucunuzun (Apache, Nginx, LiteSpeed) tüm genel erişilebilir dosyaları okuyup sunduğu sunucu tarafı klasörüdür. `www` dizini, çoğu paylaşımlı ve cPanel tabanlı ortamda, bağımsız bir depolama konumu olarak değil, tarihsel uyumluluk amacıyla var olan ve `public_html`’e işaret eden bir sembolik bağlantıdır (symlink).

Bu ayrımı anlamak yalnızca görünüşsel değildir. Dosyaları `public_html` dışına yanlış yerleştirmek, belge kökünü yanlış yapılandırmak veya symlink ilişkisini yanlış anlamak; bozuk dağıtımlara, 403 Forbidden hatalarına ya da hassas yapılandırma dosyalarının istemeden kamuya açılmasına yol açabilir.

`public_html`’in Belge Kökü Olarak Rolü

Sunucunuza bir HTTP isteği ulaştığında, web sunucusu arka plan programı hangi dizinin istenen alan adıyla eşleştiğini belirlemek için yapılandırmasına başvurur. Bu dizine belge kökü denir. Neredeyse tüm paylaşımlı barındırma ortamlarında ve cPanel ya da benzeri kontrol panelleri çalıştıran çoğu VPS Hosting yapılandırmasında bu belge kökü `public_html`’dir.

Tipik bir cPanel sunucusundaki mutlak yol şu şekilde görünür:

“`

/home/username/public_html/

“`

Bu dizine yerleştirilen her dosya, alan adınız üzerinden genel erişime açık hale gelir. Eşleme doğrudandır:

Son satır kritik öneme sahiptir. Dizin ağacında `public_html`’in üzerine yerleştirilen — doğrudan `/home/username/` içindeki — dosyalar web sunucusu tarafından görünmez ve HTTP üzerinden alınamaz. Bu, uygulamanızın çalışma zamanında okuduğu ancak hiçbir zaman kamuya sunulmaması gereken veritabanı kimlik bilgileri, `.env` dosyaları ve API anahtarları gibi hassas dosyalar için doğru konumdur.

Varsayılan Dizin Dosyaları ve Dizin Çözümlemesi

Bir ziyaretçi dizin URL’si istediğinde (örn. `https://example.com/`), web sunucusu o dizinde varsayılan bir dizin dosyası arar. Apache’nin `DirectoryIndex` yönergesindeki standart çözümleme sırası genellikle şöyledir:

“`

index.html > index.htm > index.php > index.cgi

“`

Bu dosyaların hiçbiri mevcut değilse ve dizin listeleme açıkça devre dışı bırakılmamışsa, sunucu 403 Forbidden döndürebilir veya dizin listesini açığa çıkarabilir — bu ciddi bir güvenlik riskidir. Her zaman geçerli bir dizin dosyasının mevcut olduğundan veya `Options -Indexes`’ın `.htaccess` dosyanızda ayarlandığından emin olun.

`www` Dizini Aslında Nedir

`www` dizini, kendi inode’u ve depolama tahsisi olan gerçek bir dizin değil, bir POSIX sembolik bağlantısıdır. Bunu herhangi bir Linux tabanlı sunucuda doğrulayabilirsiniz:

“`bash

ls -la ~/

“`

Çıktı şuna benzer bir şey gösterecektir:

“`

lrwxrwxrwx 1 user user 10 Jan 15 09:22 www -> public_html

drwxr-xr-x 12 user user 4096 Jan 15 09:22 public_html

“`

İzin dizesinin başındaki `l` ve `-> public_html` oku bunun bir symlink olduğunu doğrular. Bu şu anlama gelir:

• `www` ve `public_html` tamamen aynı inode verisini paylaşır
• `~/www/contact.html`’e dosya yazmak, `~/public_html/contact.html`’e yazmakla aynıdır
• `www`’i silmek, `public_html`’i veya içeriklerini silmez
• Symlink’i yeniden oluşturmak son derece kolaydır: `ln -s ~/public_html ~/www`

`www` Symlink’i Neden Var

`www` symlink’i pratik köklere sahip eski bir kalıntıdır. Erken Unix tabanlı barındırma ortamlarında, web içeriğini tam anlamıyla `www` adlı bir dizinde depolama geleneği vardı — bu, 1990’larda yaygınlaşan `www.` alt alan adı önekini yansıtıyordu. cPanel, `public_html`’i belge kökü adı olarak standartlaştırdıkça, `www` symlink’i şunları bozmamak için korundu:

• `~/www/`’e yazmak üzere sabit kodlanmış eski dağıtım betikleri
• `www` klasörü bekleyen FTP istemcileri ve dosya yöneticileri
• Yükleme hedefi olarak `www`’e atıfta bulunan belgeler ve eğitimler

Modern bir ortamda tüm pratik amaçlar için `public_html`’i kurallı konum olarak ele almalı ve `www`’i tamamen görmezden gelmelisiniz.

`public_html` ile `www`: Doğrudan Karşılaştırma

`public_html` İçindeki Dizin Yapısı

İyi organize edilmiş bir `public_html` dizini, sorumlulukları açıkça ayırır. PHP tabanlı bir site veya WordPress kurulumu için üretime yakın gerçekçi bir yapı şöyledir:

“`

public_html/

├── index.php

├── .htaccess

├── wp-config.php ← WordPress config (ideally moved one level up)

├── wp-content/

│ ├── themes/

│ ├── plugins/

│ └── uploads/

├── assets/

│ ├── css/

│ ├── js/

│ └── images/

└── sitemap.xml

“`

Kritik güvenlik notu: `wp-config.php` veritabanı kimlik bilgilerini içerir. WordPress, bu dosyayı `public_html`’in bir dizin üstüne (`/home/username/wp-config.php`) yerleştirmeyi destekler; burada HTTP üzerinden erişilemez ancak PHP tarafından okunabilir. Bu, birçok yöneticinin gözden kaçırdığı bir güçlendirme en iyi uygulamasıdır.

Alt Alan Adları ve Eklenti Alan Adları Bu Yapıyı Nasıl Genişletir

VPS Kontrol Panelleri veya cPanel üzerinden bir alt alan adı ya da eklenti alan adı oluşturduğunuzda, barındırma sistemi yeni bir belge kökü oluşturur — ya `public_html` içinde ya da aynı düzeyde paralel bir dizin olarak.

Alt Alan Adı Belge Kökleri

“`

/home/username/public_html/blog/ → blog.example.com

/home/username/public_html/shop/ → shop.example.com

“`

Ya da bazı cPanel yapılandırmalarında:

“`

/home/username/blog.example.com/ → blog.example.com

“`

Eklenti Alan Adı Belge Kökleri

“`

/home/username/public_html/newdomain/ → newdomain.com

“`

Ya da üst düzey kardeş olarak:

“`

/home/username/newdomain.com/ → newdomain.com

“`

Tam yol, barındırma paneli yapılandırmanıza bağlıdır. Dosyaları yanlış konuma yüklemekten kaçınmak için cPanel’de Domains > Subdomains veya Addon Domains altında belge kökünü her zaman doğrulayın.

Barındırma Ortamları Arasındaki Davranış Farklılıkları

Paylaşımlı Barındırma (cPanel)

cPanel ile Paylaşımlı Web Barındırma‘da yapı standartlaştırılmıştır:

• Belge kökü: `/home/username/public_html/`
• `www` symlink: varsayılan olarak mevcut
• `.htaccess` desteğiyle Apache: etkin
• Birden fazla alan adı: her biri kendi alt dizinini veya paralel klasörünü alır

VPS ve Özel Sunucular

Bir Özel Sunucu veya kendi kendine yönetilen VPS’te, belge kökü tamamen web sunucusu yapılandırmasında yönetici tarafından tanımlanır. Yaygın kurallar:

Apache Virtual Host (`/etc/apache2/sites-available/example.com.conf`):

“`apache

<VirtualHost *:80>

ServerName example.com

ServerAlias www.example.com

DocumentRoot /var/www/example.com/public_html

</VirtualHost>

“`

Nginx Server Block (`/etc/nginx/sites-available/example.com`):

“`nginx

server {

listen 80;

server_name example.com www.example.com;

root /var/www/example.com/public_html;

index index.php index.html;

}

“`

Bu ortamlarda `public_html` teknik bir gereklilik değil, bir adlandırma kuralıdır. Belge kökü, web sunucusu yapılandırması ona işaret ettiği sürece herhangi bir şey olarak adlandırılabilir — `/var/www/html/`, `/srv/www/`, `/opt/app/public/`. `www` symlink’i, siz manuel olarak oluşturmadıkça genellikle mevcut değildir.

cPanel VPS

Bir cPanel ile VPS, bir VPS’in esnekliğini paylaşımlı barındırmanın standartlaştırılmış `public_html` yapısıyla birleştirir ve bu makalede açıklandığı gibi hem `www` hem de `public_html`’in bir arada bulunduğu en yaygın ortam haline getirir.

Dosya İzinleri: Sıkça Gözden Kaçan Bir Gereklilik

Hatalı izinler, 403 Forbidden hatalarının ve başarısız dağıtımların en yaygın nedenlerinden biridir. Web erişilebilir dosyalar için standart izin modeli:

İzinleri yinelemeli olarak şununla ayarlayın:

“`bash

find ~/public_html -type d -exec chmod 755 {} ;

find ~/public_html -type f -exec chmod 644 {} ;

“`

Üretim ortamındaki herhangi bir dosya veya dizinde asla `777` ayarlamayın. Bu, tüm sistem kullanıcılarına yazma erişimi verir ve sunucu güvenliğinin ihlali için doğrudan bir vektördür.

SSL, HTTPS ve Belge Kökü

Alan adınıza bir SSL Sertifikası yüklediğinizde, sertifika belirli bir dizine değil alan adı adına bağlanır. Ancak HTTPS sanal ana bilgisayar yapılandırması, HTTP yapılandırmasıyla aynı `public_html` belge köküne işaret etmelidir. HTTP’nin bir dizinden, HTTPS’nin ise başka bir dizinden sunulduğu bir uyumsuzluk, teşhis edilmesi son derece güç tutarsız davranışlara yol açar.

Certbot aracılığıyla Let’s Encrypt kullanıyorsanız, ACME meydan okuma doğrulama süreci `public_html/.well-known/acme-challenge/`’e geçici dosyalar yerleştirir. Bu yolun, gizli dizinlere (`.` ile başlayanlar) erişimi reddeden `.htaccess` kuralları veya Nginx `location` blokları tarafından engellenmediğinden emin olun.

Pratik Temel Kontrol Listesi

Sitenizi yüklemeden önce:

• Barındırma panelinizde tam belge kökü yolunu doğrulayın — her zaman `/home/username/public_html/` olduğunu varsaymayın
• Yinelenen dosya yönetiminden kaçınmak için `www`’in ayrı bir dizin değil symlink olduğunu doğrulayın
• Hassas yapılandırma dosyalarını (`.env`, veritabanı kimlik bilgileri) `public_html`’in üstüne taşıyın

Dağıtım sırasında:

• Dizin izinlerini `755` ve dosya izinlerini `644` olarak ayarlayın
• Dizin listesini önlemek için belge kökünde bir `index.html` veya `index.php` bulunduğundan emin olun
• Derinlemesine savunma tedbiri olarak `Options Indexes`’i `.htaccess`’de devre dışı bırakın

Çok alan adlı kurulumlar için:

• Her alt alan adı ve eklenti alan adı için belge kökünü ayrı ayrı doğrulayın
• Tüm alan adlarının aynı `public_html`’i paylaştığını varsaymayın

VPS ve özel ortamlarda:

• Belge kökünü sanal ana bilgisayar veya sunucu bloğu yapılandırmanızda açıkça tanımlayın
• `www` symlink’i varsayılan olarak mevcut değildir — yalnızca eski betikler gerektiriyorsa oluşturun
• Herhangi bir yapılandırma değişikliğinden sonra web sunucusunu yeniden başlatın: `systemctl reload apache2` veya `systemctl reload nginx`

Güvenlik sertleştirmesi için:

• API anahtarlarını, `.env` dosyalarını veya veritabanı yapılandırmalarını asla `public_html` içinde saklamayın
• Özellikle `uploads/` dizinlerinde beklenmedik dosyalar için `public_html`’i periyodik olarak denetleyin
• SSL sanal ana bilgisayarınızın HTTP yapılandırmasıyla aynı belge köküne işaret ettiğinden emin olun

Sıkça Sorulan Sorular

`www` dizinini silersem ne olur?

`www` bir sembolik bağlantıysa (neredeyse tüm cPanel ortamlarında öyledir), onu silmek web sitenizi veya dosyalarını etkilemez. Gerçek içerik `public_html`’de yaşadığından siteniz normal şekilde çalışmaya devam eder. Symlink’i istediğiniz zaman `ln -s ~/public_html ~/www` ile yeniden oluşturabilirsiniz.

`public_html`’i başka bir şeyle yeniden adlandırabilir miyim?

Paylaşımlı barındırmada hayır — kontrol paneli, `public_html`’i belge kökü olarak kullanmak üzere sabit kodlanmıştır. Kendi kendine yönetilen bir VPS veya özel sunucuda, belge kökünü istediğiniz şekilde adlandırabilirsiniz; yeter ki web sunucusu yapılandırmasını (Apache’de `DocumentRoot`, Nginx’te `root`) buna göre güncelleyin.

Dosyalarım `public_html`’de olmasına rağmen neden 403 Forbidden hatası alıyorum?

En yaygın nedenler şunlardır: hatalı dosya izinleri (dosyaların en az `644`’e, dizinlerin `755`’e ihtiyacı vardır), dizin listeleme devre dışıyken eksik dizin dosyası veya erişimi engelleyen bir `.htaccess` kuralı. Belirli neden için web sunucusu hata günlüğünü (`/var/log/apache2/error.log` veya `/var/log/nginx/error.log`) kontrol edin.

PHP’nin okumas gereken ancak genel erişime açık olmaması gereken dosyaları nerede saklamalıyım?

Bunları `public_html`’in üstündeki bir dizine, örneğin `/home/username/private/`’e veya doğrudan `/home/username/`’e yerleştirin. PHP, web sunucusu kullanıcısının erişim iznine sahip olduğu dosya sistemindeki herhangi bir yerdeki dosyaları okuyabilir, ancak web sunucusu belge kökü dışındaki dosyaları HTTP üzerinden sunmaz.

`www` alt alan adı, sunucu düzeyinde www olmayan alan adından farklı mı çalışır?

Hayır. Hem `www.example.com` hem de `example.com`, DNS yapılandırması ve sanal ana bilgisayar ayarları aracılığıyla aynı belge köküne çözümlenir. Dosya sistemindeki `www` dizin symlink’i, `www.` DNS alt alan adıyla ilgisizdir — bunlar aynı üç harfi paylaşan ayrı kavramlardır.