Headscale ile Kendi Tailscale Sunucunuzu Barındırma

headscale nedir

Headscale, Tailscale kontrol sunucusunun kendi sunucunuzda barındırılan bir uygulamasıdır. Bu nedenle özel ağınızı koordine eden makine, sahibi olduğunuz bir VPS olur. Bu bir topluluk projesidir ve Tailscale Inc. tarafından işletilmez. Her makinede resmi tailscale istemcisi çalışmaya devam eder. İstemci, tek bir --login-server flag'i ile sunucunuza yönlendirilir.

Kontrol sunucusu, ağa kimlerin dahil olduğunu bilir. Her düğüme 100.64.0.0/10 aralığından bir adres verir, public key'leri dağıtır ve düğümlere birbirlerini nerede bulacaklarını bildirir. Tüneller, düğümler arasında kurulan WireGuard tünelleri olarak kalır. İki makineniz arasındaki trafik, doğrudan bir yol kurulamazsa ve düğümler bir relay kullanmaya geçmezse headscale sunucusundan geçmez.

Headscale, her instance için bir tailnet (tek bir Tailscale ağı) sunar. Proje bunu kişisel kullanım veya küçük bir kuruluş için uygun olarak tanımlar. Üç veya dört makine için sahip olduğunuz bir VPS üzerinde düz bir WireGuard VPN çalıştırmak, işletilecek daha az yazılım ve bozulacak daha az bileşen anlamına gelir. Headscale, her yeni dizüstü bilgisayar için elle bir [Peer] bloğu yazmak istemediğinizde avantaj sağlar. İki modelin daha kapsamlı karşılaştırması için WireGuard ile Tailscale arasındaki farklara bakın.

Kuruluma başlamadan önce gerekenler

• Genel IPv4 adresine ve sudo erişimine sahip, Ubuntu 24.04 çalıştıran bir VPS. Sunucu yeniyse önce yeni bir VPS üzerindeki ilk on dakika kılavuzunu uygulayın.
• Bu adresi gösteren bir DNS A kaydı. Bu kılavuzda headscale.example.com kullanılır.
• MagicDNS için ikinci bir alan adı veya alt alan adı. Bu kılavuzda tailnet.example.net kullanılır. Bu alan adı, server_url içindeki alan adıyla aynı olmamalıdır.
• Linux, macOS, Windows, Android veya iOS çalıştıran ve ağa katılacak bir istemci makinesi.

Resmi .deb paketinden headscale kurulumu

Proje, GitHub sürümleri sayfasında .deb paketlerini yayımlar. Temmuz 2026 itibarıyla geçerli sürüm 0.29.3'tür. Önce mimariyi kontrol edin. Çünkü dosya adı mimariyi içerir.

sudo apt update
sudo apt install -y wget
dpkg --print-architecture

Bu komut, normal bir x86 VPS üzerinde amd64, Ampere veya Graviton türü bir planda ise arm64 çıktısını verir. Aşağıdaki değişkende bu yanıtı kullanın.

HEADSCALE_VERSION="0.29.3"
HEADSCALE_ARCH="amd64"
wget --output-document=headscale.deb \\
  "https://github.com/juanfont/headscale/releases/download/v${HEADSCALE_VERSION}/headscale_${HEADSCALE_VERSION}_linux_${HEADSCALE_ARCH}.deb"
sudo apt install -y ./headscale.deb
headscale version

Dosya adının önündeki ./ gereklidir. Bu ifade olmadan apt, depolarınızda headscale.deb adlı bir paket arar ve başarısız olur.

Paket bir headscale sistem kullanıcısı oluşturur, varsayılan bir /etc/headscale/config.yaml yazar ve bir systemd birimi kurar. Hizmeti başlatmaz. Doğru sıra budur. Paketle birlikte gelen yapılandırma, server_url değerini http://127.0.0.1:8080 adresine yönlendirir. Bu adres, istemcilerinizin hiçbirinin erişemeyeceği bir adrestir. Bu nedenle hizmet şimdi başlatılırsa çalışmaya başlasa bile yapılandırma hatalı olur. Bu aşamada sudo systemctl is-active headscale çalıştırıldığında inactive çıktısı alınır. Bu beklenen bir durumdur ve hata değildir.

Hizmeti başlatmadan önce server_url değerini yapılandırın

/etc/headscale/config.yaml dosyasını sudo nano /etc/headscale/config.yaml ile düzenleyin veya aynı üç değişikliği sed ile uygulayın. Özgün dosyanın bir kopyasını saklayın. Dosya uzun ve kapsamlı açıklamalar içerir. Kalan ayarlar için en iyi başvuru kaynağıdır.

sudo cp /etc/headscale/config.yaml /etc/headscale/config.yaml.orig
sudo sed -i 's|^server_url:.*|server_url: https://headscale.example.com|' /etc/headscale/config.yaml
sudo sed -i 's|^listen_addr:.*|listen_addr: 127.0.0.1:8080|' /etc/headscale/config.yaml
sudo sed -i 's|^  base_domain:.*|  base_domain: tailnet.example.net|' /etc/headscale/config.yaml
sudo grep -E '^(server_url|listen_addr):|^  base_domain:' /etc/headscale/config.yaml

server_url, headscale tarafından her istemci kaydına yazılan adrestir. İstemciler bundan sonra tam olarak bu dizeye bağlanır. Bu nedenle değer, başında https:// bulunan genel ad olmalıdır; hiçbir zaman 127.0.0.1 olmamalıdır.

listen_addr, işlemin hangi adrese bağlanacağını belirtir. Değeri loopback üzerinde bırakın. Aynı sunucudaki bir reverse proxy, TLS'yi (transport layer security) sonlandırır ve isteği bu adrese iletir. Bu nedenle sunucu dışındaki hiçbir bileşenin 8080 portuna erişmesi gerekmez.

base_domain, MagicDNS sonekidir. Düğümlerinizin adlandırıldığı etki alanıdır. Sondaki nokta olmadan tam nitelikli bir etki alanı adı olmalıdır. Ayrıca server_url içinde kullanılan etki alanından farklı olmalıdır. Aksi durumda iki ad alanı çakışır.

Veritabanı bölümünü değiştirmeyin. Varsayılan veritabanı, /var/lib/headscale/db.sqlite konumundaki SQLite'tır. Bu konum, paket tarafından oluşturulmuş ve sahipliği pakete ait bir dizindir. SQLite, bu büyüklükteki bir tailnet için yeterlidir.

headscale'i başlatma ve çalıştığını doğrulama

sudo systemctl enable --now headscale
sudo systemctl is-active headscale
curl -sS -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8080/health

is-active, active çıktısını verir; curl ise 200 çıktısını verir. enable --now her iki işlemi de gerçekleştirir: hizmeti başlatır ve yeniden başlatma sonrasında otomatik olarak başlatılacak şekilde işaretler.

is-active, failed çıktısını verirse günlüğü sudo journalctl -u headscale -n 50 --no-pager ile okuyun. Bu aşamadaki hata neredeyse her zaman yapılandırma dosyasından kaynaklanır. Bunun nedeni, headscale'in soket açmadan önce dosyanın tamamını ayrıştırmasıdır. Bu nedenle hatalı girinti veya bilinmeyen bir anahtar, işlem herhangi bir bağlantı noktasını dinlemeye başlamadan önce işlemi durdurur. Dosyayı düzeltin, ardından sudo systemctl restart headscale çalıştırın. Bundan sonraki her yapılandırma değişikliğinde aynı yeniden başlatma işlemi gerekir. İstemciler daha sonra kendiliğinden yeniden bağlanır. systemd birimleri sizin için yeniyse, systemd ile kendi hizmetlerinizi ve zamanlayıcılarınızı çalıştırma burada kullanılan komutları açıklar.

Shell içindeyken durum dosyalarını da kontrol edin:

stat -c '%U %n' /var/lib/headscale/db.sqlite /var/lib/headscale/noise_private.key

Her iki satır da paketin oluşturduğu ayrıcalıksız kullanıcı olan headscale ile başlar. noise_private.key, sunucunun istemcilerine karşı kimliğidir. Bu dosyayı koruyun. Dosyayı silerseniz headscale yeni bir kimlik oluşturur ve her düğümün yeniden kaydolması gerekir.

headscale'in önüne TLS eklenmesi

İstemcilerin server_url hizmetine HTTPS üzerinden erişmesi gerekir. Caddy en kısa yoldur; sertifikayı kendisi ister ve yeniler.

sudo apt install -y caddy

/etc/caddy/Caddyfile yerine headscale belgelerindeki bloğu yerleştirin:

headscale.example.com {
    reverse_proxy 127.0.0.1:8080 {
        header_up True-Client-IP {remote_host}
        header_up X-Real-IP {remote_host}
    }
}

sudo caddy validate --adapter caddyfile --config /etc/caddy/Caddyfile
sudo systemctl restart caddy
sudo systemctl is-active caddy

Dosya ayrıştırıldığında validate, adapted config to JSON çıktısını verir. Dosyanın biçimlendirilmediğine ilişkin uyarı yalnızca görünüşseldir. Dizüstü bilgisayarınızdan curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health komutu da 200 çıktısını vermelidir. Bu tek denetim, DNS'in, güvenlik duvarının, sertifikanın ve proxy'nin birlikte çalıştığını doğrular.

İnsanların bir akşamını harcamasına neden olan proxy ayrıntısı şudur: Tailscale denetim bağlantısı bir HTTP yükseltmesidir, GET yerine POST ile başlatılır ve Upgrade başlığının değeri tailscale-control-protocol olur. Caddy bunu ek yapılandırma olmadan iletir. nginx ise iletmez. Bu nedenle nginx ön yüzünün yükseltme eşlemesine ihtiyacı vardır:

map $http_upgrade $connection_upgrade {
    default keep-alive;
    ''      close;
}

server {
    listen 443 ssl;
    server_name headscale.example.com;
    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        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_buffering off;
        proxy_pass http://127.0.0.1:8080;
    }
}

Bu satırları eklentiden çıkarırsanız normal istekler yine başarılı olur. Bu nedenle /health 200 döndürür ve her şey düzgün görünür. Ancak uzun süreli denetim bağlantısı kurulamaz. Düğümler kaydolur ve ardından çevrimdışı durumda kalır. nginx kullanmayı seçerseniz Ubuntu 24.04 üzerinde nginx ile Certbot, sertifika bölümünü açıklar.

UFW'de açılacak portlar

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

443 numaralı port, tüm istemci iletişimini taşır. 80 numaralı port yalnızca ACME (otomatik sertifika yönetimi ortamı) HTTP challenge işlemi ve HTTPS'ye yönlendirme için kullanılır. Ayrıca Caddy'nin sertifika alabilmesi için bu porta ihtiyacı vardır.

8080 numaralı port kapalı kalır. listen_addr, 127.0.0.1:8080 olduğundan proxy, headscale'e loopback arayüzü üzerinden ulaşır ve herhangi bir firewall kuralı gerekmez. 8080 numaralı portun internete açılması, istemcilere şifrelenmemiş bir kontrol kanalı sağlar ve başka bir yarar getirmez. Çoğu sağlayıcının kontrol panelinde, UFW'den ayrı ikinci bir firewall çalıştırdığı unutulmamalıdır. Bu nedenle bir port sunucuda açık olsa bile ağ sınırında kapalı olabilir. VPS üzerinde UFW firewall temelleri, kural söz dizimini daha ayrıntılı olarak açıklar.

Kullanıcı ve preauth anahtarı oluşturma

sudo headscale users create alice
sudo headscale users list

headscale komutu bir istemcidir. Çalışan daemon ile /var/run/headscale/headscale.sock unix soketi üzerinden iletişim kurar. Bu soketin modu 0770'dır ve sahibi headscale grubudur. Bunun iki sonucu vardır. Hizmet durdurulmuşsa komut başarısız olur. Bu, bu kılavuzdaki sıralamanın önemli olmasının diğer nedenidir. Ayrıca kendi hesabınızı headscale grubuna eklemediğiniz sürece sudo gerekir.

users list her adın yanında bir kimlik yazdırır. Bu numara gerekir. Çünkü key komutu ad değil, sayısal kullanıcı kimliği alır.

sudo headscale preauthkeys create --user 1 --expiration 24h

Anahtar yalnızca bir kez yazdırılır. Hemen kopyalayın. Preauth anahtarı tek kullanımlıktır ve aksi belirtilmediği sürece bir saat geçerlidir. Bu nedenle test sürecine devam ederken --expiration 24h ayarının yapılması yararlıdır. Birden fazla makineyi kaydeden bir anahtar için --reusable ekleyin. Bu anahtarı parola gibi koruyun. Çünkü anahtara sahip olan herkes ağınıza katılabilir.

Ilk istemcinizi --login-server ile bağlama

Katılmak istediğiniz makinede:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --login-server https://headscale.example.com --auth-key 'hskey-auth-PASTE-YOUR-KEY-HERE'
tailscale status
tailscale ip -4

tailscale ip -4, headscale tarafından atanan adresi 100.64.0.1 benzeri bir biçimde yazdırır. Sunucuya dönüp sudo headscale nodes list komutunu çalıştırdığınızda düğüm; kimliği, kullanıcısı ve çevrimiçi durumu ile birlikte gösterilir.

--login-server değerinin, şema dahil ve sondaki eğik çizgi olmadan, server_url ile tam olarak eşleşmesi gerekir. Değerler dize olarak karşılaştırılır. Eşleşmeme durumunda istemci bir adrese kaydolur, ardından başka bir adresle iletişim kurması istenir.

Daha önce Tailscale'in barındırılan hizmetinde oturum açılmış bir makinede bu oturum korunur. Önce sudo tailscale logout komutunu çalıştırın, ardından --login-server ile tailscale up komutunu çalıştırın.

--auth-key seçeneğini belirtmezseniz istemci bunun yerine bir URL yazdırır. Bu URL'yi açın. Sayfada, sunucuda onaylamanız gereken kayıt denemesinin tanımlayıcısı gösterilir:

sudo headscale auth register --user alice --auth-id PASTE-THE-ID-FROM-THE-PAGE

Bu form, kişisel dizüstü bilgisayarınız için daha uygundur. Betiklerle çalıştırılan işlemler için ön kimlik doğrulama anahtarları daha uygundur; böylece işlemi bir kişinin izlemesi gerekmez.

DERP ve doğrudan yol başarısız olduğunda trafiği aktaran geçiş noktaları

DERP (paketler için belirlenmiş şifreli geçiş noktası), yedek yoldur. İki düğüm doğrudan WireGuard bağlantısı açamadığında, bunun nedeni genellikle her ikisinin de katı NAT (ağ adresi çevirisi) arkasında bulunmasıdır. Bu durumda paketler bunun yerine bir geçiş noktası üzerinden gönderilir. Geçiş noktası hiçbir anahtara sahip değildir. Bu nedenle trafiğinizi okuyamaz. Ancak hangi düğümlerin iletişim kurduğunu ve ne kadar veri aktarıldığını görür.

Varsayılan yapılandırmanın ne yaptığını açıkça bilin. Headscale, https://controlplane.tailscale.com/derpmap/default adresini auto_update_enabled: true ve update_frequency: 3h ile göstererek gelir. Böylece denetim düzlemi size ait olur, ancak geçiş noktalarınız Tailscale'e ait olur. Çoğu kullanıcı için bu makul bir ödünleşmedir. Sizin için uygun değilse kendi geçiş noktanızı çalıştırın.

Kendi geçiş noktanızı çalıştırmak için config.yaml içindeki derp.server altında enabled: true değerini ayarlayın, headscale hizmetini yeniden başlatın ve STUN (NAT için oturum geçiş yardımcı programları) portunu sudo ufw allow 3478/udp ile açın. Yapılandırma dosyası gereksinimi açıkça belirtir: server_url https kullanmalıdır, çünkü DERP TLS gerektirir. derp.urls listesinin boşaltılması, Tailscale geçiş noktalarını haritadan kaldırır. Çalışan bir gömülü geçiş noktası olmadan bunu yaparsanız, doğrudan bağlanamayan düğüm çiftleri hiçbir şekilde bağlanamaz.

Bir istemciden tailscale netcheck komutu, bildiği her geçiş noktası bölgesine olan gecikmeyi yazdırır. tailscale status ise her eşin adres içeren direct veya bölge kodu içeren relay olduğunu belirtir. relay durumunda takılı kalan bir eş, headscale sorunu değil, NAT sorunudur.

Bir node neden çevrimdışı görünüyor?

Proxy, yükseltme isteğini iletiyor. Bu en yaygın durumdur. Belirtisi, diğer her şeyin sağlıklı görünmesidir: /health 200 döndürür, headscale nodes list node'u gösterir, ancak node çevrimiçi olmaz. Denetim bağlantısı Upgrade: tailscale-control-protocol içeren bir POST isteğidir. Bu isteği iletmeyen bir proxy, node durumunu bildiren tek kanalı keser. nginx yapılandırmanızı yukarıdaki map bloğuyla karşılaştırın veya proxy kaynaklı sorunu dışlamak için Caddy'ye geçin.

Node'lar kaydolduktan sonra server_url değişti. Node'lar, kayıt sırasında kendilerine verilen değere bağlanmayı sürdürür. Bu değeri düzenlediyseniz her node üzerinde sudo tailscale up --login-server https://headscale.example.com --force-reauth komutunu çalıştırın.

İstemci çalışmıyor. Node üzerinde sudo systemctl is-active tailscaled ve sudo journalctl -u tailscaled -n 50 --no-pager komutlarını çalıştırın. Alan adınızı çözemeyen veya alan adınıza erişemeyen bir istemci, yeniden deneme işlemlerini burada günlüğe kaydeder.

Anahtarın süresi doldu. Bu konu sonraki bölümde açıklanmıştır.

Test sırasında sunucu tarafını izlemek için VPS üzerinde sudo journalctl -u headscale -f komutunu çalıştırın ve istemci üzerinde tailscaled komutunu yeniden başlatın. headscale'e ulaşan bir node hemen günlük satırları üretir. Herhangi bir çıktı yoksa istek sunucuya ulaşmıyordur. Bu durumda headscale'i incelemeden önce DNS'i, güvenlik duvarını ve proxy'yi kontrol edin.

Anahtar süresinin dolması ve haftalar sonra çalışmayı durduran düğüm

İki ayrı süre sonu vardır. Bunların karıştırılması zaman kaybına yol açar.

Preauth anahtarlarının süresi tasarım gereği kısa sürede dolar. Varsayılan değer bir saat ve bir kullanımdır. tailscale up anahtarı kabul etmezse istemcide herhangi bir şeyi düzenlemek yerine sunucuda yeni bir anahtar oluşturulmalıdır.

Düğüm anahtarları uzun süre geçerli olan kısımdır. config.yaml dosyasındaki node bölümü expiry: 0 değerini ayarlar. 0 ise varsayılan süre sonu olmadığı anlamına gelir: kaydedilmiş bir düğümün süresi siz sona erdirene kadar dolmaz. Etiketli düğümlerin süresi hiçbir durumda dolmaz. Kayıtların belirli bir süre sonra geçersiz olmasını istiyorsanız expiry: 180d ayarlanmalıdır. Ancak bunun sonucunu dikkate alın: etiketlenmemiş her düğümün bu zamanlamaya göre sudo tailscale up --login-server https://headscale.example.com --force-reauth işlemini gerçekleştirmesi gerekir. Kimsenin yeniden kimlik doğrulaması yapmadığı başsız bir sunucunun ağ bağlantısı kendiliğinden kesilir.

Birisi dizüstü bilgisayarını kaybettiğinde işlemi elle yapın. sudo headscale nodes list size kimliği verir. Ardından sudo headscale nodes expire -i 3 bu düğümün oturumunu kapatır ve sudo headscale nodes delete -i 3 düğümü ağdan tamamen kaldırır.

Yedeklemeler ve yükseltmeler

/var/lib/headscale ve /etc/headscale birlikte sunucunun tamamını oluşturur. Kopyalamadan önce hizmeti durdurun. SQLite üzerinde devam eden yazma işlemleri olabilir. Yük altında kopyalanan bir veritabanı tutarsız olabilir.

sudo systemctl stop headscale
sudo tar czf /root/headscale-state.tgz -C /var/lib headscale
sudo tar czf /root/headscale-config.tgz -C /etc headscale
sudo systemctl start headscale
sudo chmod 600 /root/headscale-*.tgz

Her iki dosyayı da sunucudan başka bir konuma taşıyın. Bu dosyalar özel anahtarları ve tüm kayıtları içerir. Bu nedenle sunucunun kendisiyle aynı özenle korunmaları gerekir. VPS için restic yedeklemeleri, bu işlemin zamanlanmış ve şifrelenmiş şekilde nasıl yapılacağını açıklar.

Yükseltmeler kurulum işlemini tekrarlar: yeni .deb ve sudo apt install ./headscale.deb dosyalarını indirin, ardından hizmeti yeniden başlatın ve is-active ile /health denetimlerini tekrar çalıştırın. 0.29 sürümünden itibaren yükseltme yolu katıdır. Küçük sürüm atlamak engellenir. Daha eski bir küçük sürüme dönmek de engellenir. Her seferinde bir küçük sürüm ilerleyin. Her adımdan önce yedek alın. Önce ilgili sürümün sürüm notlarını okuyun. Çünkü aynı sürüm ACL politikası davranışını değiştirdi ve çeşitli yapılandırma anahtarlarının konumunu değiştirdi.

FAQ

.deb paketini kurduktan hemen sonra headscale neden başlatılamıyor?

Paket birimi kurar, ancak hizmeti durdurulmuş bırakır ve varsayılan /etc/headscale/config.yaml çalışan bir yapılandırma yerine şablondur. Önce server_url, listen_addr ve base_domain dosyalarını düzenleyin. Ardından sudo systemctl enable --now headscale komutunu çalıştırın ve sudo systemctl is-active headscale ile doğrulayın. Sorun devam ederse sudo journalctl -u headscale -n 50 --no-pager sorunun kaynağını gösterir. Bu aşamada sorun neredeyse her zaman bir YAML hatasıdır. Bunun nedeni headscale'in bir porta bağlanmadan önce dosyanın tamamını ayrıştırmasıdır.

Makinelerime normal Tailscale istemcisini yine de kurmalı mıyım?

Evet. Headscale yalnızca kontrol sunucusunun yerini alır. Her düğüm, Tailscale tarafından sağlanan resmi istemciyi çalıştırır. İstemciyi sudo tailscale up --login-server https://headscale.example.com ile sunucunuza yönlendirirsiniz. Bu flag standart istemcide bulunur. Bu nedenle herhangi bir düzeltme veya yeniden derleme gerekmez.

Trafiğim headscale sunucusundan mı geçer?

Genellikle hayır. Headscale ağı koordine eder, anahtarları ve adresleri dağıtır. Veri yolu ise düğümleriniz arasında doğrudan WireGuard bağlantısıdır. Trafik yalnızca iki düğüm birbirine doğrudan ulaşamadığında ve DERP relay üzerinden bağlantıya geçtiğinde dolambaçlı bir yol izler. Sağlanan yapılandırmada bu relay'ler Tailscale'in herkese açık relay'leridir. Belirli bir eşin direct veya relay üzerinde olup olmadığını görmek için bir düğümde tailscale status komutunu çalıştırın.

Düğümüm kaydolduktan sonra neden çevrimdışı kalıyor?

headscale nodes list içinde görünen ancak hiçbir zaman çevrimiçi olmayan bir düğüm, genellikle reverse proxy üzerindeki kontrol bağlantısını kaybetmiştir. Bu bağlantı, Upgrade: tailscale-control-protocol başlığıyla gönderilen bir HTTP upgrade isteğidir. nginx, map $http_upgrade $connection_upgrade bloğu ile buna karşılık gelen proxy_set_header satırlarını eklemediğiniz sürece bu isteği düşürür. Caddy, ek yapılandırma olmadan bu isteği iletir. Bu nedenle proxy'nin soruna neden olup olmadığını test etmek için hızlı bir seçenek sunar.

headscale için alan adı ve TLS gerekli mi?

Uygulamada evet. İstemciler server_url içine yazdığınız dizeye bağlanır. Sertifikalar çıplak IP adresleri için değil, adlar için düzenlenir. Yapılandırma dosyasında DERP için TLS gerektiği belirtilir. Alan adı ve Caddy kurulumu yaklaşık beş dakika sürer ve kendisini yenileyen bir HTTPS uç noktası sağlar. Kontrol sunucusunun plain HTTP üzerinden çalıştırılması, her istemci görüşmesinin internet üzerinden şifrelenmemiş olarak iletilmesi anlamına gelir.