ServBay Web Sitesini Genel Internete Yayınlama (Ters Proxy, Tünel ve Port Yönlendirme)

Yerel geliştirme dışında, birçok kullanıcı ServBay’i sürekli çalışan bir sunucuya (veri merkezinde barındırılan Mac mini, ofiste sabit sunucu, Windows sunucusu vb.) kurarak arka uç kaynak sunucusu (origin server) olarak yapılandırır ve sitesini genel internete açar. Bu uygulama üretim ortamlarında tamamen mümkündür—çok sayıda kullanıcı bu şekilde sorunsuz hizmet vermektedir.

Ancak, ServBay’in varsayılan ağ davranışını iyi anlamadan protokol, sertifika, Host başlığı veya ağ ayarlarında yapılan yanlışlar sonucunda “yerelde her şey çalışıyor, ama internetten erişilemiyor” gibi sorunlar yaşanabilir. ServBay’i arka uç kaynak olarak kullanmak isteyen herkese yönelik hazırlanan bu yazıda, ilk olarak varsayılan davranışlar açıklanıyor, ardından "Entegre Tünel → Ters Proxy (önerilir) → Port Yönlendirme" sıralamasıyla tam çözüm yolları sunuluyor ve sonunda sık karşılaşılan erişim problemleri için genel bir kontrol listesi ekleniyor.

Uygulama Platformları

Bu rehber ServBay for macOS ve ServBay for Windows için geçerlidir. Her iki platformdaki site protokol modları, dinleme davranışları ve sertifika yolları aynıdır; yalnızca kurulum klasörleri farklıdır (macOS için /Applications/ServBay, Windows genellikle C:\ServBay). Varsayılan web sunucuları ise: macOS’de varsayılan olarak Caddy, Windows’ta varsayılan olarak Nginx gelir; her ikisi de Nginx/Apache/Caddy arasında değiştirilebilir.

ServBay’in Varsayılan Ağ Davranışını Anlamak

Genel internetten erişimle ilgili sorunların çoğu, aşağıdaki varsayılan davranışların yanlış anlaşılmasından kaynaklanır:

Varsayılan site protokolü HTTP & HTTPS’tir. Bu modda, HTTP (80) istekleri koşulsuz olarak 301 ile HTTPS (443)’e yönlendirilir. Bu, modernleşmiş bir varsayılan değerdir—HTTP yerine HTTPS kullanmanız teşvik edilir, şifresiz 80’i kullanmaya dönmemeniz önerilir.
HTTPS, SNI ile site ve sertifikayı seçer. Aynı ServBay üzerinde birden fazla web sitesi SNI (bağlantı sırasında aktarılan sunucu adı) üzerinden eşleştirilir. Ters proxy kullanırken HTTPS üzerinden geri bağlantı yapılacaksa, doğru SNI kesinlikle iletilmelidir, aksi halde varsayılan site/sertifika döner.
Varsayılan olarak tüm ağ arayüzlerinde dinleme yapar (0.0.0.0), portlar ise HTTP için 80 / HTTPS için 443’tür ve dış bağlantıya açıktır, genellikle IP bağlama ayarını değiştirmenize gerek yoktur.
Yerel HTTPS sertifikaları ServBay CA tarafından imzalanır. ServBay kendi entegre CA’sı ile (Anahtar Zincirinde ServBay User CA - ECC Root olarak görünür) siteler için sertifika üretir. Ancak internetten gelen ziyaretçilerin tarayıcıları bu CA’ya güvenmez—ön taraftaki ters proxy’de CA’ya güvenilmesi (veya doğrulamanın atlanması) yeterlidir, kaynak bağlantısı için ayrıca genel bir sertifika başvurusuna gerek yoktur.

Tipik Hata: HTTP & HTTPS + Sadece 80’i Yönlendirmek

Eğer siteyi HTTP & HTTPS modunda bırakıp yalnızca 80’i (HTTPS portunu) yönlendirir, 443’ü atarsanız: istemci http://alan_adı ile istek atar → ServBay 301 ile https://alan_adı’ya döner → tarayıcı 443’e bağlanır → cevap yok → erişim hatası yaşanır. Ayrıca tarayıcı veya HSTS bu 301’i önbelleğe alır, sorunun çözümünü daha da zorlaştırır.

Doğru çözüm HTTPS’yi çalışır hale getirmektir (aşağıdaki ters proxy bölümüne bakınız).

Üç Yayınlama Yöntemi ve Seçim Kriterleri

Yöntem	Açıklama	Kullanım Durumu
Entegre Tünel (frpc / cloudflared vb.)	ServBay içerisinde gömülüdür, dışarıya kendiliğinden tünel açar, genel IP’ye veya port açmaya gerek yoktur	Genel IP yoksa, ev/farklı NAT ağı kullanılıyorsa ya da hızlıca yayına ihtiyaç varsa
Ters Proxy (önerilir)	Nginx/HAProxy/Caddy/Traefik gibi bir ön sunucu, genel trafikleri ve sertifikaları yönetir, ServBay’e HTTPS ile geri bağlantı yapar	Genel giriş noktasına sahip, çoklu arka uç/tek noktadan sertifika yönetimi isteyenler
Port Yönlendirme (NAT)	Gateway, genel portları doğrudan ServBay sunucusuna yönlendirir	Tekil arka uç var ve detayları biliyorsanız

1. Yöntem: Entegre Tünel (En Kolayı, Genel IP Yok Gerekmez)

Eğer genel bir IP yoksa veya ters proxy ve sertifikalarla uğraşmak istemiyorsanız, ServBay’in entegre tünel servisleri en zahmetsiz çözümdür. ServBay’den dışarıya bağlantı açtığı için NAT, IPv6, port yönlendirme, sertifika güveni vb. konularda sorun yaşanmaz:

Cloudflare Tunnel (cloudflared) — Sitenizi Cloudflare’in global ağı üstünden internete açar, otomatik olarak güvenilen HTTPS sağlar, port açmaya gerek yoktur. Kararlı genel alan adı ve CDN/WAF isteyenler için uygundur.
frp (frpc) — Kendi frps sunucunuza bağlanır, tamamen sizin kontrolünüzdedir.
ngrok / Pinggy — Hızlıca geçici bir URL oluşturur, demo veya Webhook entegrasyonları için idealdir.

Birçok kullanıcı için, sadece cloudflared ile bir tünel açmak "yerel siteyi genel internete açmak" için yeterli olup, aşağıdaki ters proxy/port yönlendirme adımlarına gerek kalmayabilir.

2. Yöntem: Ters Proxy + HTTPS Geri Bağlantı (Önerilir)

Üretim ortamlarında önerilen yöntem budur: Önde bir ters proxy ile genel, güvenilir HTTPS sunun, ServBay’e geri bağlantı da HTTPS üzerinden olsun (siteyi HTTP & HTTPS modunda tutun) ve uçtan uca şifrelemeyi sağlayın.

Neden HTTPS Geri Bağlantı, Neden HTTP 80’e Dönülmemeli?

Çoğu rehber hâlâ “arka uçta HTTP, proxy’de şifresiz bağlantı” formülünü anlatıyor. Biz bu yöntemi önermiyoruz, özel bir zorunluluk ve masrafını net olarak anlamadığınız sürece:

Uçtan uca şifreleme: Ters proxy ile ServBay arasında dahi olsa, tüm trafik şifrelenir ve iç ağda dinleme/manipülasyon engellenir.
Modern Protokol Avantajları: HTTPS ile HTTP/2 (h2) kullanılabilir, çoklu kanal, başlık sıkıştırma ve bağlantı paylaşımı gibi performans faydaları elde edilir; şifresiz 80 portu ise sizi eski paradigmalara hapseder.
Versiyan Düşürmenin Yol Açtığı Sorunları Önleme: HTTP’ye dönünce, HTTP & HTTPS’nin 301 yönlendirmeleri, HSTS önbelleği, uygulama katmanı https bağlantı üretimi gibi bir dizi sorunla boğuşmak zorunda kalırsınız.
ServBay CA’ya Güvenmek Çok Kolay: ServBay’in kendi self-signed CA’sı ile sorun yaşamazsınız—tek yapmanız gereken, ters proxy tarafında bu CA’ya güvenmek veya doğrulamayı atlamaktır, bir kez yapılandırılır ve uzun vadede çalışır.

Sadece HTTP 80 ile devam etmek için 3. Yönteme bakınız, sadece özel durumlara ve etkisini tam olarak bilenlere önerilir.

Genel Anahtar Noktalar

Aşağıdaki unsurlar dört popüler ters proxy için de aynıdır. Örneklerin tamamında genel alan adınız: example.com, ServBay arka ucu: 192.168.1.115, arka uç HTTPS portu: 443, ServBay sitesi ise HTTP & HTTPS modunda çalışıyor.

HTTPS Geri Bağlantı: Ters proxy’de proxy_pass veya upstream https://192.168.1.115:443 olmalı.
Doğru SNI’nin Gönderilmesi: SNI ServBay’deki site domain’i ile birebir aynı olmalı (example.com), yoksa doğru site/sertifika çalışmaz.
ServBay CA’ya güven veya doğrulamayı atla: CA dosyasının nasıl alınacağı bir sonraki bölümde.
Host Başlığını Olduğu Gibi Aktar: Host: example.com, ServBay’deki server_name kontrolü için gereklidir.
X-Forwarded-Proto: https başlığı ekle: Arka uç uygulamalar orijinal çağrının https olduğunu doğru anlar, böylece yanlış http link üretme veya sonsuz yönlendirme hatası yaşamazsınız.
IPv4 / IPv6 Tutarlılığını Sağlayın: IPv4/IPv6 tutarlılığı bölümüne bakınız.

ServBay CA Nasıl Alınır? (Ters Proxy'nin ServBay Sertifikasına Güvenmesi İçin)

ServBay’in yerel root CA sertifikası, kurulum dizininde yer alır:

macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (kurulum yolunuza göre değişebilir)

Bu .crt dosyasını ters proxy sunucunuza (örn. /etc/nginx/servbay-ca/) kopyalayın ve proxy ayarlarında kaynak sertifikası olarak tanıtın.

Sertifika Zinciri Hakkında

ServBay’de “root CA + ara CA” zinciri uygulanır, siteyi imzalayan sertifika aslında ara CA’dandır. Sadece root CA’yı tanımak bazen doğrulamada hata yaratır; bu durumda root ve intermediate (aynı klasörde, ServBay-Private-CA-ECC-Intermediate.crt) dosyalarını tek bir bundle’a birleştirip proxy tarafında kullanınız; ya da önce doğrulamayı atlayıp bağlantınızı test eder, ardından sert sertifika kontrolüne geçersiniz.

Nginx ile Ters Proxy (HTTPS Geri Bağlantı)

nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # IPv6 desteği gerekirse
    server_name example.com;

    # Genel kullanıma açık güvenilir sertifika (örn. Let's Encrypt)
    ssl_certificate     /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    location / {
        proxy_pass https://192.168.1.115:443;                 # HTTPS ile geri bağlantı

        # —— Anahtar: SNI ve kaynak doğrulaması ——
        proxy_ssl_server_name on;                             # SNI gönder
        proxy_ssl_name        example.com;                    # SNI = ServBay domain
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # CA’yı tanımladıktan sonra doğrulama açılır
        proxy_ssl_verify_depth 2;                             # Root + ara sertifika
        # Kolay yöntem (CA yoksa): proxy_ssl_verify off;

        # —— Anahtar: Host ve protokol aktarımı ——
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# HTTP'den HTTPS'ye yönlendirme (proxy üstünde tutarlı merkezi yönlendirme)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

HAProxy ile Ters Proxy (HTTPS Geri Bağlantı)

haproxy

frontend fe_web
    bind :80
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem
    http-request redirect scheme https unless { ssl_fc }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    default_backend be_servbay

backend be_servbay
    option forwardfor
    http-request set-header Host example.com
    # HTTPS geri bağlantı: ssl + SNI gönderimi + ServBay CA doğrulaması
    server servbay1 192.168.1.115:443 ssl sni str(example.com) \
        verify required ca-file /etc/haproxy/servbay-ca/servbay-ca-bundle.crt
    # Kolay yöntem: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Caddy ile Ters Proxy (HTTPS Geri Bağlantı)

Caddy, example.com için otomatik olarak genel sertifika başvurusu ve yenilemesi yapar, reverse_proxy Host ve X-Forwarded-* başlıklarını varsayılan olarak geçirir:

caddy

example.com {
    reverse_proxy https://192.168.1.115:443 {
        header_up Host {host}
        transport http {
            tls_server_name example.com                                  # SNI
            tls_trusted_ca_certs /etc/caddy/servbay-ca/servbay-ca-bundle.crt
            # Kolay yöntem: tls_insecure_skip_verify
        }
    }
}

Traefik ile Ters Proxy (HTTPS Geri Bağlantı)

file provider ile dinamik bir örnek:

yaml

# traefik-dynamic.yml
http:
  routers:
    servbay:
      rule: "Host(`example.com`)"
      entryPoints:
        - websecure
      service: servbay
      tls:
        certResolver: letsencrypt
  services:
    servbay:
      loadBalancer:
        passHostHeader: true                 # Host başlığını geçir
        servers:
          - url: "https://192.168.1.115:443" # HTTPS üzerinden geri bağlantı
        serversTransport: servbay-tls

serversTransports:
  servbay-tls:
    serverName: example.com                  # SNI
    rootCAs:
      - /etc/traefik/servbay-ca/servbay-ca-bundle.crt
    # Kolay yöntem: insecureSkipVerify: true

3. Yöntem: Port Yönlendirme (NAT)

Eğer tek bir arka uç kullanıyorsanız, gateway veya router üzerinden genel portları doğrudan ServBay makinenize yönlendirebilirsiniz (örnek iç ağ IP’si: 192.168.1.115).

Tavsiye: 443’ü yönlendirin, HTTPS’yi koruyun

Gateway port yönlendirmesi: Genel 443 → 192.168.1.115:443 (isteğe bağlı olarak Genel 80 → 192.168.1.115:80, böylelikle ServBay otomatik olarak 80’den 443’e yönlendirir).
DNS’de A kaydını genel IPv4’e yönlendirin.
Siteyi HTTP & HTTPS modunda tutun. Genel ziyaretçi direkt olarak ServBay’e bağlandığında ilgili alan adı için genel internetten güvenli sertifika kurmak gereklidir (aşağıdaki sertifika bölümüne bakınız), aksi halde tarayıcı sertifika hatası verecektir.
IPv4 / IPv6 tutarlılığını kontrol edin (aşağıdaki bölüm).

HTTP 80’i Direkt Yayınlama (Sadece Özel Durumlar İçin)

Sadece 80’i yönlendirip siteyi HTTP moduna almak, HTTPS ve HTTP/2 avantajlarının tamamını kaybettirir; ayrıca tarayıcı HSTS veya önbellekleme ile çakışma sorunu getirir. Yalnızca zorunlu ve teknik etkisini net bilenler için önerilir. Gerçekten gerekiyorsa: site protokolünü açıkça HTTP olarak ayarlayın (443’e yönlendirilmeye çalışılmasın diye), sadece 80’i yönlendirin.

IPv4/IPv6 Tutarlılığı

Genel erişimin dengesiz olması çoğunlukla bu yüzden kaynaklanır. Alan adınızda hem A (IPv4) hem de AAAA (IPv6) kaydı varsa, istemciler Happy Eyeballs algoritması ile bazen öncelikle IPv6 üzerinden erişmeye çalışır; sadece IPv4’e yönlendirme/ters proxy yaptıysanız, IPv6 istekleri başarısız olur. Çözüm önerileri:

Sadece IPv4 kullan: dig AAAA alan_adınız +short çıktısının boş olduğuna emin olun, yalnızca A kaydınız olsun.
Hem IPv4 hem IPv6 destekle: IPv6 için de yönlendirme ekle, proxy’de [::] dinlenmesi gerektiğinden emin ol, arka uca IPv6 ile de erişilebilsin.

Erişim Hataları İçin Kontrol Listesi

Genel erişimde hata (açılamıyor, zaman aşımı, sertifika hatası, yanlış site vs.) olursa şu adımları sırayla kontrol edin (domain: example.com, arka uç: 192.168.1.115):

301 mi yanıtlıyor, ama 443 yok mu?
bash
```
curl -I http://example.com
```
1
Yanıt 301 ve Location: https://..., ama 443 ayarlanmamışsa → sorun budur. HTTPS’yi çalıştırın (önerilir) veya siteyi HTTP moduna çekin.

IPv6 problem mi yaratıyor?

bash

curl -4 -I https://example.com     # Sadece IPv4
curl -6 -I https://example.com     # Sadece IPv6
dig A example.com +short
dig AAAA example.com +short        # AAAA var ve IPv6 erişilemiyorsa → sil veya düzelt

Kaynakta SNI/Sertifika doğru mu? (HTTPS geri bağlantıda) Arka uca doğrudan SNI ile erişin:
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Sertifika/matching hatası varsa genellikle SNI yanlış veya CA tanınmamış demektir.
İstek ServBay’e ulaşıyor mu? ServBay sunucusunda, ilgili site için web sunucu access loglarını kontrol edin (“Log dosyasını görüntüle” menüsünden). Zaman aşımı gibi isteklere log’da rastlamıyorsanız, sorun ağ/gateway/proxy katmanındadır.
Host başlığı doğru mu? (L7 proxy senaryosu)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Arka uca doğrudan erişim başarılı, proxy üstünden başarısızsa → proxy Host başlığını geçirmiyor demektir.

Sertifika ve Güvenlik

Geri Kaynak Zinciri: Ters proxy’den ServBay’e HTTPS ile giderken, proxy tarafında ServBay CA’ya (ServBay-Private-CA-ECC-Root.crt, gerekiyorsa ara sertifikayla) güvenin; bu iç ağ için bir defa yapılandırılıp sürekli geçerli olur.
Genel Sertifikalar: Genel ziyaretçiler için kullanılan sertifika internet tarafından güvenilen sertifika olmalıdır. Ters proxy’de (Caddy/Traefik) otomatik yönetilebilir; port yönlendirmede ise ilgili domain için ServBay’e geçerli genel sertifika yüklenmelidir, ACME yöntemiyle sertifika başvurusu rehberine bakınız. ServBay’in kendi self-signed ServBay User CA’sı yalnızca yerel/ağ içi için uygundur, genel ziyaretçi için geçerli değildir.
Veritabanlarını Asla Açıkta Tutmayın: Genel internete yalnızca web portları açılmalı, MySQL, Redis, Memcached gibi servisler kesinlikle açılmamalıdır. Ek güvenlik notları için LAN erişimi deneyin.
Güvenlik Duvarı: Yalnızca gerekli portları açık bırakın, diğer tüm portları kapalı tutun.

Sık Sorulan Sorular (SSS)

S: Yerelde her şey çalışıyor ama internetten erişilemiyor, DNS sorunu mu?
- C: Çoğu zaman “çözümleme olmuyor” değil, HTTP & HTTPS’in 301’i 443’e yönlendiriyor ama 443 yok, SNI/cert eşleşmiyor, Host başlığı geçirilmemiş veya IPv4/IPv6 tutarsızlığından dolayıdır. Kontrol listesini adım adım uygulayın.
S: Ters proxy’yi çalıştırmak için illa HTTP 80’e dönmeli miyim?
- C: Hayır, gerek de yok. HTTP & HTTPS modunu tutup, proxy ile HTTPS geri bağlantı + ServBay CA’ya güvenerek (veya doğrulamayı atlayarak) uçtan uca şifreleme ve HTTP/2 kullanabilirsiniz.
S: Proxy kaynak bağlantıda sertifika/alan adı hatası veriyor?
- C: Doğru SNI’nin (site domain’i) gönderildiğinden, proxy’de ServBay CA’nın (ile gerekiyorsa ara sertifika) tanıtıldığından emin olun. Hızlı test için doğrulamayı atlayıp ardından sıkı kontrole geçebilirsiniz.
S: ServBay üretimde kaynak sunucu olarak güvenilir mi?
- C: Evet. Çok sayıda kullanıcı ServBay’i Mac mini / Windows sunucularda veri merkezlerinde stabil şekilde kullanıyor. Kritik olan; protokol modu, SNI, Host başlığı, sertifika güveni ve IPv4/IPv6 tutarlılığıdır.
S: Genel IP’m yok, ne yapmalıyım?
- C: 1. Yöntemi: Entegre Tünel kullanın (cloudflared / frpc), genel IP veya port yönlendirme gerekmez.

Sonuç

ServBay’i arka uç kaynak sunucu olarak genel internete yayınlamak teknik olarak tamamen mümkündür. Önerilen yöntem şudur: Sitenizi HTTP & HTTPS modunda bırakın, ön tarafta bir ters proxy ile HTTPS üzerinden geri bağlantı, doğru SNI gönderimi ve ServBay CA’ya güven tanımı sayesinde uçtan uca şifreleme ile HTTP/2 gibi modern faydalara sahip olun; genel IP’niz yoksa, entegre cloudflared / frpc tünel çözümü en zahmetsizidir; port yönlendirme ise detaylara hakim olan kullanıcılar içindir. Bir erişim problemiyle karşılaşınca, bu belgeye ait kontrol listesini adım adım uygulayarak hızla tespit sağlayabilirsiniz—sorunlar neredeyse her zaman protokol modu, SNI/sertifika, Host başlığı veya IPv4/IPv6 uyumsuzluğuna dayanır.

ServBay Web Sitesini Genel Internete Yayınlama (Ters Proxy, Tünel ve Port Yönlendirme) ​

ServBay’in Varsayılan Ağ Davranışını Anlamak ​

Üç Yayınlama Yöntemi ve Seçim Kriterleri ​

1. Yöntem: Entegre Tünel (En Kolayı, Genel IP Yok Gerekmez) ​

2. Yöntem: Ters Proxy + HTTPS Geri Bağlantı (Önerilir) ​

Neden HTTPS Geri Bağlantı, Neden HTTP 80’e Dönülmemeli? ​

Genel Anahtar Noktalar ​

ServBay CA Nasıl Alınır? (Ters Proxy'nin ServBay Sertifikasına Güvenmesi İçin) ​

Nginx ile Ters Proxy (HTTPS Geri Bağlantı) ​

HAProxy ile Ters Proxy (HTTPS Geri Bağlantı) ​

Caddy ile Ters Proxy (HTTPS Geri Bağlantı) ​

Traefik ile Ters Proxy (HTTPS Geri Bağlantı) ​

3. Yöntem: Port Yönlendirme (NAT) ​

IPv4/IPv6 Tutarlılığı ​

Erişim Hataları İçin Kontrol Listesi ​

Sertifika ve Güvenlik ​

Sık Sorulan Sorular (SSS) ​

Sonuç ​