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ă | Da | Opțional |
| Certificat SSL independent | Da (sau wildcard) | Partajat cu domeniul rădăcină |
| Tratat ca site separat de Google | Adesea, în funcție de conținut | Nu |
| Server / VPS separat posibil | Da | Necesită proxy invers |
| Domeniu de aplicare sesiune / cookie | Separat implicit | Partajat |
| Complexitate configurare | Moderată | Scăzută |
| Ideal pentru | Aplicații, staging, site-uri regionale | Secț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.comsaudev.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ă țintireahreflangș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 +shortDacă 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:
- Conectați-vă la interfața de gestionare DNS.
- Localizați secțiunea DNS Zone Editor, DNS Management sau Zone File.
- 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âmp | Valoare |
|---|---|
| Tip | A |
| Nume / Gazdă | blog (nu blog.example.com) |
| Valoare / Direcționează către | 203.0.113.42 (IP-ul public al serverului dvs.) |
| TTL | 3600 (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âmp | Valoare |
|---|---|
| Tip | AAAA |
| Nume / Gazdă | blog |
| Valoare | 2001:db8::1 |
| TTL | 3600 |
Î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âmp | Valoare |
|---|---|
| Tip | CNAME |
| Nume / Gazdă | shop |
| Valoare / Țintă | shops.myplatform.com. (observați punctul final — semnalează un FQDN) |
| TTL | 3600 |
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âmp | Valoare |
|---|---|
| Tip | A |
| Nume / Gazdă | * |
| Valoare | 203.0.113.42 |
| TTL | 3600 |
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:
- Conectați-vă la cPanel.
- Navigați la Domenii > Subdomenii.
- În câmpul Subdomeniu, introduceți eticheta (de ex.,
blog). - Selectați domeniul rădăcină din lista derulantă.
- Setați Rădăcina Documentelor — cPanel implicit la
public_html/blog, dar puteți specifica orice cale. - 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 nginxConfigurarea 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 apache2Pasul 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.comSau pentru Apache:
sudo certbot --apache -d blog.example.comCertbot 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 +tracePentru 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 -datesVerificați că:
- Răspunsul
curl -Ireturnează200 OKsau codul de redirecționare așteptat. - Subiectul certificatului TLS corespunde
blog.example.comsau*.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ăzduire | Gestionare DNS | Configurare Server Web | Furnizare SSL |
|---|---|---|---|
| Găzduire Partajată | Registrator sau Zonă DNS cPanel | Expert Subdomenii cPanel | AutoSSL / Let’s Encrypt în cPanel |
| VPS (neadministrat) | Registrator sau DNS extern | vhost Nginx / Apache manual | Certbot CLI |
| VPS cu cPanel | WHM / DNS cPanel sau extern | Expert Subdomenii cPanel | AutoSSL |
| Server Dedicat | Registrator sau BIND/PowerDNS | Manual sau panou de control | Certbot sau CA comercial |
| Cloud (AWS, GCP) | Route 53 / Cloud DNS | Reguli load balancer / ingress | ACM / 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 +shortpentru a confirma înainte de a vă conecta la orice panou. - Înregistrare A sau CNAME? Utilizați
A/AAAApentru un IP de server. UtilizațiCNAMEpentru un nume de gazdă al unei platforme terțe. Nu utilizați niciodatăCNAMEla 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
300cu 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: noindexla nivel de server sau utilizați HTTP Basic Auth. - Sunt domeniile de aplicare ale cookie-urilor definite corect? Setați explicit atributul
Domainpe 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.
