15%

Economisește 15% la toate serviciile de găzduire

Testează-ți abilitățile și obține Reducere la orice plan de găzduire

Utilizați codul:

Skills
Începeți
22.10.2024

Cum să Adăugați un Subdomeniu la Domeniul Dvs.

Un subdomeniu este un prefix adăugat unui domeniu rădăcină care creează un spațiu de nume distinct, adresabil independent, sub același nume de domeniu. De exemplu, dat fiind domeniul rădăcină example.com, numele de gazdă blog.example.com este un subdomeniu complet calificat unde blog este eticheta de nivel trei. Subdomeniile sunt rezolvate prin înregistrări DNS — de obicei o înregistrare A care indică o adresă IPv4, o înregistrare AAAA pentru IPv6, sau o înregistrare CNAME care aliasează un alt nume de gazdă — și nu necesită nicio taxă suplimentară de înregistrare a domeniului.

Din punct de vedere practic, subdomeniile vă permit să rulați aplicații web separate, medii de staging, site-uri regionale sau microservicii sub un singur domeniu înregistrat, cu rădăcini de documente independente, certificate SSL și configurații de server. Acest ghid acoperă procesul tehnic complet: crearea înregistrărilor DNS, configurarea găzduirii, furnizarea SSL, verificarea propagării și modurile comune de eșec pe care majoritatea tutorialelor le omit.

Ce Este un Subdomeniu și Cum Diferă de un Subdirector

Înainte de a atinge DNS, merită să înțelegeți diferența arhitecturală dintre un subdomeniu și un subdirector, deoarece alegerea afectează SEO, configurarea serverului și domeniul de aplicare SSL.

CaracteristicăSubdomeniu (`blog.example.com`)Subdirector (`example.com/blog`)
Înregistrare DNS necesarăDa (A, AAAA sau CNAME)Nu
Rădăcină de documente separatăDaOpțional
Certificat SSL independentDa (sau wildcard)Partajat cu domeniul rădăcină
Tratat ca site separat de GoogleAdesea, în funcție de conținutNu
Server / VPS separat posibilDaNecesită proxy invers
Domeniu de aplicare sesiune / cookieSeparat implicitPartajat
Complexitate configurareModeratăScăzută
Ideal pentruAplicații, staging, site-uri regionaleSecțiuni de blog, pagini de produse

John Mueller de la Google a confirmat că Google tratează în general subdomeniile ca parte a aceluiași site atunci când conținutul este clar corelat, dar comportamentul bugetului de crawl, indexării și echității linkurilor poate diferi. Pentru conținut strâns integrat, cum ar fi un blog al companiei, un subdirector este adesea alegerea cu mai puține complicații. Pentru o aplicație separată — un portal pentru clienți, un gateway API sau un mediu de staging — un subdomeniu este decizia arhitecturală corectă.

Cazuri de Utilizare Comune pentru Subdomenii

  • Medii de staging și QA: staging.example.com sau dev.example.com — izolate de producție, adesea protejate prin HTTP Basic Auth sau liste de permisiuni IP.
  • Endpoint-uri API: api.example.com — permite implementare independentă, limitarea ratei și terminarea TLS.
  • Portaluri pentru clienți sau tablouri de bord SaaS: app.example.com — context de autentificare separat și cookie-uri de sesiune.
  • Site-uri regionale sau specifice limbii: de.example.com, us.example.com — suportă țintirea hreflang și rutarea serverului specifică geografiei.
  • Documentație și suport: docs.example.com, support.example.com — adesea servite de pe platforme precum GitBook, Zendesk sau un wiki auto-găzduit.
  • CDN sau livrare media: cdn.example.com, static.example.com — CNAME-uri direcționate către o rețea CDN edge.
  • Infrastructură de mail: mail.example.com — utilizat ca nume de gazdă pentru serviciile SMTP/IMAP, distinct de înregistrările MX.

Pasul 1: Accesați Interfața de Gestionare DNS

Înregistrările DNS pentru un domeniu sunt gestionate acolo unde sunt găzduite serverele de nume autoritare ale domeniului. Acesta nu este întotdeauna același loc cu găzduirea web. Serverul de nume autoritar este definit de înregistrările NS la registratorul domeniului dvs.

Determinați unde este gestionat DNS-ul dvs.:

dig NS example.com +short

Dacă rezultatul arată servere de nume aparținând registratorului dvs. (de ex., ns1.registrar.com), gestionați DNS la registrator. Dacă arată servere de nume aparținând unui furnizor de găzduire sau unui serviciu precum Cloudflare, gestionați DNS acolo în schimb.

Odată ce ați identificat panoul de control corect:

  1. Conectați-vă la interfața de gestionare DNS.
  2. Localizați secțiunea DNS Zone Editor, DNS Management sau Zone File.
  3. Selectați domeniul pentru care doriți să creați subdomeniul.

Dacă domeniul dvs. este înregistrat prin Înregistrare Domenii AlexHost, editorul de zone DNS este accesibil direct din tabloul de bord al zonei client.

Pasul 2: Creați Înregistrarea DNS pentru Subdomeniu

Veți crea unul dintre cele trei tipuri de înregistrări în funcție de infrastructura dvs.

Înregistrare A — Direcționare către o Adresă IPv4

Utilizați o înregistrare A atunci când subdomeniului i se rezolvă o adresă IP specifică a serverului. Acesta este cel mai comun scenariu pentru subdomeniile găzduite pe un VPS sau Server Dedicat.

CâmpValoare
TipA
Nume / Gazdăblog (nu blog.example.com)
Valoare / Direcționează către203.0.113.42 (IP-ul public al serverului dvs.)
TTL3600 (sau 300 în timpul configurării inițiale pentru iterații mai rapide)

Detaliu critic: Introduceți doar eticheta subdomeniului în câmpul Nume — blog, nu blog.example.com. Majoritatea interfețelor DNS adaugă automat domeniul rădăcină. Introducerea FQDN-ului complet va crea o înregistrare pentru blog.example.com.example.com.

Înregistrare AAAA — Direcționare către o Adresă IPv6

Structură identică cu înregistrarea A, dar valoarea este o adresă IPv6 completă:

CâmpValoare
TipAAAA
Nume / Gazdăblog
Valoare2001:db8::1
TTL3600

Înregistrare CNAME — Aliasarea unui Alt Nume de Gazdă

Utilizați o înregistrare CNAME atunci când subdomeniului trebuie să i se rezolve un alt nume de gazdă în loc de un IP direct. Scenariile comune includ direcționarea către un CDN, o platformă terță (Shopify, HubSpot, Netlify) sau un alt nume de gazdă intern.

CâmpValoare
TipCNAME
Nume / Gazdăshop
Valoare / Țintăshops.myplatform.com. (observați punctul final — semnalează un FQDN)
TTL3600

Constrângere arhitecturală: O înregistrare CNAME nu poate coexista cu niciun alt tip de înregistrare la aceeași etichetă. Nu puteți crea un CNAME pentru example.com însuși (apex-ul zonei) — doar pentru subdomenii. La apex, utilizați o înregistrare A sau, dacă furnizorul dvs. DNS o suportă, o înregistrare proprietară ALIAS sau ANAME.

Înregistrare Subdomeniu Wildcard

O înregistrare A wildcard rezolvă orice subdomeniu nedefinit la un singur IP:

CâmpValoare
TipA
Nume / Gazdă*
Valoare203.0.113.42
TTL3600

Acest lucru este util pentru aplicațiile SaaS multi-tenant unde fiecare client primește un subdomeniu (de ex., customer1.example.com). Rețineți că o înregistrare DNS wildcard nu furnizează automat SSL pentru fiecare subdomeniu — aveți nevoie de un certificat SSL wildcard sau un client ACME care suportă provocări DNS-01.

Pasul 3: Configurați Serverul Web sau Panoul de Găzduire

Crearea unei înregistrări DNS face subdomeniului rezolvabil, dar nu servește automat conținut. Trebuie să configurați serverul web sau panoul de găzduire pentru a accepta și ruta cererile pentru noul nume de gazdă.

Configurarea unui Subdomeniu în cPanel

Dacă găzduirea dvs. utilizează cPanel — disponibil pe planurile VPS cu cPanel — procesul este:

  1. Conectați-vă la cPanel.
  2. Navigați la Domenii > Subdomenii.
  3. În câmpul Subdomeniu, introduceți eticheta (de ex., blog).
  4. Selectați domeniul rădăcină din lista derulantă.
  5. Setați Rădăcina Documentelor — cPanel implicit la public_html/blog, dar puteți specifica orice cale.
  6. Faceți clic pe Creare.

cPanel creează automat înregistrarea DNS A în zona BIND a WHM dacă DNS-ul domeniului este gestionat local. Dacă DNS-ul este gestionat extern (de ex., Cloudflare), trebuie să adăugați înregistrarea acolo manual, așa cum este descris în Pasul 2.

Configurarea unui Subdomeniu în Nginx

Pentru un VPS care rulează Nginx, creați un nou bloc server:

server {
    listen 80;
    listen [::]:80;
    server_name blog.example.com;

    root /var/www/blog;
    index index.html index.php;

    access_log /var/log/nginx/blog.access.log;
    error_log  /var/log/nginx/blog.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Salvați fișierul în /etc/nginx/sites-available/blog.example.com, apoi activați-l:

sudo ln -s /etc/nginx/sites-available/blog.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Configurarea unui Subdomeniu în Apache

Creați un nou fișier virtual host la /etc/apache2/sites-available/blog.example.com.conf:

<VirtualHost *:80>
    ServerName blog.example.com
    DocumentRoot /var/www/blog

    <Directory /var/www/blog>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog  ${APACHE_LOG_DIR}/blog.error.log
    CustomLog ${APACHE_LOG_DIR}/blog.access.log combined
</VirtualHost>

Activați și reîncărcați:

sudo a2ensite blog.example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Pasul 4: Furnizați un Certificat SSL pentru Subdomeniu

Fiecare subdomeniu care servește trafic web ar trebui securizat cu TLS. Un subdomeniu este un nume de gazdă distinct și nu este acoperit de certificatul cu un singur domeniu al domeniului rădăcină, cu excepția cazului în care utilizați un certificat wildcard.

Opțiunea 1 — Let’s Encrypt cu Certbot (Subdomeniu Unic)

sudo certbot --nginx -d blog.example.com

Sau pentru Apache:

sudo certbot --apache -d blog.example.com

Certbot modifică automat configurația virtual host și configurează un cron job pentru reînnoire.

Opțiunea 2 — Certificat Wildcard Let’s Encrypt (Provocare DNS-01)

Un certificat wildcard acoperă *.example.com, securizând toate subdomeniile actuale și viitoare cu un singur certificat. Aceasta necesită verificarea provocării DNS-01:

sudo certbot certonly 
  --manual 
  --preferred-challenges dns 
  -d "*.example.com" 
  -d "example.com"

Certbot vă va solicita să creați o înregistrare TXT (_acme-challenge.example.com) în zona dvs. DNS. După adăugarea înregistrării și verificarea propagării, Certbot emite certificatul. Certificatele wildcard trebuie reînnoite la fiecare 90 de zile; automatizați reînnoirea cu un plugin DNS pentru furnizorul dvs. (de ex., certbot-dns-cloudflare).

Opțiunea 3 — Certificat SSL Comercial

Pentru organizațiile care necesită validare extinsă (EV) sau o perioadă de valabilitate mai lungă, un certificat comercial de la o CA de încredere este adecvat. AlexHost oferă Certificate SSL inclusiv opțiuni validate prin domeniu, validate prin organizație și wildcard. După achiziție, instalați certificatul plasând fișierele .crt și .key pe server și referindu-le în configurația virtual host.

Pasul 5: Verificați Propagarea DNS

Modificările DNS nu intră în vigoare global în momentul în care le salvați. Fiecare rezolver memorează în cache înregistrările pentru durata valorii TTL. Cu un TTL de 3600, rezolvoarele pot servi înregistrarea veche timp de până la o oră după ce efectuați o modificare.

Verificați propagarea din mai multe puncte globale de observație:

# Check from a specific DNS resolver
dig A blog.example.com @8.8.8.8 +short
dig A blog.example.com @1.1.1.1 +short

# Check authoritative answer directly
dig A blog.example.com +trace

Pentru o verificare vizuală multi-regiune, utilizați whatsmydns.net sau dnschecker.org. Propagarea globală completă se finalizează de obicei în 15 minute până la 2 ore pentru TTL-uri de 3600 sau mai mici. Adesea citatul „până la 48 de ore” se aplică în principal valorilor TTL de 86400 (24 de ore) setate pe înregistrarea anterioară — o valoare implicită comună la mulți registratori.

Sfat pro: Înainte de a efectua modificări DNS, reduceți TTL-ul înregistrării existente la 300 (5 minute) cu cel puțin un ciclu TTL în avans. Aceasta reduce dramatic timpul de așteptare al propagării în timpul modificării efective.

Pasul 6: Testați Funcționalitatea End-to-End

După propagare, efectuați un test funcțional complet:

# Confirm DNS resolution
dig A blog.example.com +short

# Confirm HTTP response
curl -I http://blog.example.com

# Confirm HTTPS and certificate validity
curl -I https://blog.example.com

# Inspect the TLS certificate
openssl s_client -connect blog.example.com:443 -servername blog.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -subject -dates

Verificați că:

  • Răspunsul curl -I returnează 200 OK sau codul de redirecționare așteptat.
  • Subiectul certificatului TLS corespunde blog.example.com sau *.example.com.
  • Data de expirare a certificatului este corectă.
  • Nu apar avertismente de conținut mixt în consola de dezvoltator a browserului.

Capcane Comune și Cum să le Evitați

CNAME la apex-ul zonei: Încercarea de a crea o înregistrare CNAME pentru example.com însuși va întrerupe livrarea mailurilor și alte înregistrări DNS. Utilizați o înregistrare A sau o înregistrare ALIAS/ANAME la apex.

Subdomeniului nu îi este servit conținut de serverul web: DNS se rezolvă corect, dar browserul returnează un 404 sau conexiunea este refuzată. Cauză: serverul web nu are un virtual host care să corespundă numelui de gazdă al subdomeniului. Soluție: adăugați blocul server sau virtual host-ul așa cum este descris în Pasul 3.

Nepotrivire certificat SSL: Browserul afișează o eroare de certificat. Cauză: certificatul existent acoperă doar example.com, nu blog.example.com. Soluție: emiteți un nou certificat specific pentru subdomeniu sau înlocuiți cu un certificat wildcard.

cPanel creează o înregistrare DNS locală, dar DNS-ul este gestionat extern: Când utilizați Cloudflare sau un alt furnizor DNS extern cu găzduire cPanel, expertul de subdomenii al cPanel creează o înregistrare în zona BIND locală a WHM, care nu este niciodată consultată. Trebuie să adăugați înregistrarea A manual în Cloudflare (sau furnizorul dvs. DNS extern). Aceasta este una dintre cele mai comune surse de confuzie pentru utilizatorii de găzduire partajată.

DNS wildcard fără SSL wildcard: O înregistrare DNS *.example.com rezolvă toate subdomeniile la serverul dvs., dar fiecare subdomeniu nou va declanșa un avertisment de certificat dacă nu aveți instalat un certificat SSL wildcard. Nu vă bazați doar pe DNS wildcard pentru subdomeniile de producție.

Scurgere domeniu de aplicare cookie: Dacă aplicația dvs. setează cookie-uri pe .example.com (observați punctul inițial), acele cookie-uri sunt trimise tuturor subdomeniilor. Aceasta poate expune token-urile de sesiune de la un subdomeniu cu securitate ridicată la unul mai puțin sigur. Definiți explicit domeniul de aplicare al cookie-urilor pentru numele de gazdă intenționat.

Gestionarea Subdomeniilor în Diferite Medii de Găzduire

Tip GăzduireGestionare DNSConfigurare Server WebFurnizare SSL
Găzduire PartajatăRegistrator sau Zonă DNS cPanelExpert Subdomenii cPanelAutoSSL / Let’s Encrypt în cPanel
VPS (neadministrat)Registrator sau DNS externvhost Nginx / Apache manualCertbot CLI
VPS cu cPanelWHM / DNS cPanel sau externExpert Subdomenii cPanelAutoSSL
Server DedicatRegistrator sau BIND/PowerDNSManual sau panou de controlCertbot sau CA comercial
Cloud (AWS, GCP)Route 53 / Cloud DNSReguli load balancer / ingressACM / Let’s Encrypt

Pentru aplicații cu trafic ridicat care necesită acces root complet și configurații personalizate de server, un Server Dedicat vă oferă control complet asupra DNS, software-ului serverului web și gestionării certificatelor fără constrângerile unui mediu partajat.

Listă de Verificare pentru Decizii Tehnice

Înainte de a crea un subdomeniu, parcurgeți următoarele:

  • Unde sunt serverele de nume autoritare? Rulați dig NS example.com +short pentru a confirma înainte de a vă conecta la orice panou.
  • Înregistrare A sau CNAME? Utilizați A/AAAA pentru un IP de server. Utilizați CNAME pentru un nume de gazdă al unei platforme terțe. Nu utilizați niciodată CNAME la apex-ul zonei.
  • Este serverul web configurat să accepte noul nume de gazdă? O înregistrare DNS singură nu servește conținut.
  • Are subdomeniului nevoie de propriul certificat SSL? Da, cu excepția cazului în care un certificat wildcard este deja instalat.
  • Este TTL-ul setat scăzut înainte de modificare? Reduceți-l la 300 cu cel puțin un ciclu TTL înainte de a efectua modificări pentru a minimiza întârzierea propagării.
  • Gestionează cPanel DNS local în timp ce un furnizor extern este autoritar? Dacă da, adăugați înregistrarea la furnizorul extern, nu în cPanel.
  • Trebuie subdomeniului să îi fie blocată indexarea de motoarele de căutare? Dacă este un mediu de staging sau intern, adăugați X-Robots-Tag: noindex la nivel de server sau utilizați HTTP Basic Auth.
  • Sunt domeniile de aplicare ale cookie-urilor definite corect? Setați explicit atributul Domain pe cookie-uri pentru a preveni partajarea neintențională între subdomenii.

Întrebări Frecvente

Pot crea un subdomeniu fără acces la DNS-ul domeniului rădăcină?

Nu. Un subdomeniu necesită o înregistrare DNS (A, AAAA sau CNAME) în zona domeniului rădăcină. Fără acces de scriere la zona DNS autoritară, nu puteți crea un subdomeniu rezolvabil public.

Afectează un subdomeniu SEO-ul domeniului rădăcină?

Depinde de relația conținutului și de linkurile interne. Google poate asocia un subdomeniu cu domeniul rădăcină, dar echitatea linkurilor nu circulă la fel de liber ca între URL-urile subdirectorului. Pentru conținut strâns integrat cu site-ul principal, un subdirector este în general preferabil din punct de vedere SEO. Pentru aplicații separate sau medii de staging, un subdomeniu este alegerea corectă și ar trebui noindex dacă nu este destinat căutării publice.

Câte subdomenii pot crea sub un domeniu?

Specificația DNS nu impune nicio limită practică privind numărul de subdomenii. Registratorii și panourile de găzduire pot impune limite soft, dar acestea sunt administrative, nu tehnice. Un singur domeniu poate avea sute de subdomenii.

Care este diferența dintre o înregistrare DNS wildcard și un certificat SSL wildcard?

O înregistrare DNS wildcard (*.example.com) direcționează toate subdomeniile nedefinite către o singură adresă IP la nivelul DNS. Un certificat SSL wildcard (*.example.com) securizează toate subdomeniile de primul nivel la nivelul TLS. Sunt independente: puteți avea unul fără celălalt, dar ambele sunt necesare pentru a servi toate subdomeniile prin HTTPS fără furnizarea individuală de certificate.

De ce subdomeniului meu i se rezolvă corect în dig dar returnează o eroare de browser?

Rezolvarea DNS și servirea HTTP sunt straturi separate. Dacă dig returnează IP-ul corect, dar browserul afișează o eroare, serverul web de pe acel IP nu este configurat să gestioneze cererile pentru acel nume de gazdă (server_name în Nginx sau ServerName în Apache). Adăugați blocul virtual host corespunzător și reîncărcați serverul web.

15%

Economisește 15% la toate serviciile de găzduire

Testează-ți abilitățile și obține Reducere la orice plan de găzduire

Utilizați codul:

Skills
Începeți