{"id":1018,"date":"2026-10-03T11:58:36","date_gmt":"2026-10-03T11:58:36","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=1018"},"modified":"2026-10-03T09:30:51","modified_gmt":"2026-10-03T09:30:51","slug":"domain-vs-url-difference","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/en\/domain-vs-url-difference\/","title":{"rendered":"Domain vs URL: What Is the Difference?"},"content":{"rendered":"<div class=\"aiw-summary\" id=\"aiw-ozet\">\n<p class=\"aiw-summary-title\">Quick Summary &#8211; Domain vs URL<\/p>\n<p>A domain is a name in the DNS hierarchy. A URL is a complete address that can include a scheme, host, port, path, query, and fragment.<\/p>\n<ul>\n<li><strong>Domain name<\/strong> \u2014 Identifies a named area in DNS, such as example.com.<\/li>\n<li><strong>Complete URL<\/strong> \u2014 Specifies how to reach a resource, such as https:\/\/example.com\/docs.<\/li>\n<li><strong>Host is separate<\/strong> \u2014 The host may contain a domain, subdomain, hostname, or IP address.<\/li>\n<li><strong>DNS layer<\/strong> \u2014 DNS resolves names and records; it does not process URL paths such as \/blog.<\/li>\n<li><strong>HTTPS matters<\/strong> \u2014 The scheme, hostname, port, and certificate must agree for a secure connection.<\/li>\n<li><strong>Test separately<\/strong> \u2014 Use dig for DNS and curl for HTTP status codes and redirects.<\/li>\n<\/ul>\n<\/div>\n<p class=\"aiw-lead\">A domain is the name, while a URL is the full address used to reach a resource. In https:\/\/example.com:8443\/docs?id=4, example.com is the domain, but the URL also tells the client to use HTTPS, connect to port 8443, request \/docs, and send a query parameter.<\/p>\n<div class=\"aiw-toc\" style=\"border:1px solid #dbe3ea;border-radius:8px;padding:16px 20px;margin:0 0 28px\">\n<p class=\"aiw-toc-head\"><strong>Table of Contents<\/strong><span class=\"aiw-toc-meta\"> \u00b7 14 min read<\/span><\/p>\n<ol style=\"margin:10px 0 0;padding-left:22px\">\n<li><a href=\"#the-basic-difference-between-a-domain-and-a-url\">The basic difference between a domain and a URL<\/a><\/li>\n<li><a href=\"#what-parts-make-up-a-url\">What parts make up a URL?<\/a><\/li>\n<li><a href=\"#what-is-a-domain-and-how-does-it-work\">What is a domain, and how does it work?<\/a><\/li>\n<li><a href=\"#how-can-you-tell-a-domain-from-a-url\">How can you tell a domain from a URL?<\/a><\/li>\n<li><a href=\"#are-domain-hostname-and-url-the-same-thing\">Are domain, hostname, and URL the same thing?<\/a><\/li>\n<li><a href=\"#how-do-https-dns-and-redirects-relate-to-domains-and-urls\">How do HTTPS, DNS, and redirects relate to domains and URLs?<\/a><\/li>\n<li><a href=\"#testing-domains-and-urls-from-the-command-line\">Testing domains and URLs from the command line<\/a><\/li>\n<li><a href=\"#common-domain-and-url-mistakes\">Common domain and URL mistakes<\/a><\/li>\n<li><a href=\"#a-short-decision-table-for-domains-and-urls\">A short decision table for domains and URLs<\/a><\/li>\n<li><a href=\"#check-these-before-troubleshooting\">Check These Before Troubleshooting<\/a><\/li>\n<li><a href=\"#frequently-asked-questions\">Frequently Asked Questions<\/a><\/li>\n<li><a href=\"#sources\">Sources<\/a><\/li>\n<\/ol>\n<\/div>\n<h2 id=\"the-basic-difference-between-a-domain-and-a-url\">The basic difference between a domain and a URL<\/h2>\n<p>I still see domain names and URLs treated as if they were interchangeable, especially when someone is troubleshooting a site at an inconvenient hour. They are related, but they answer different questions. A <strong>domain<\/strong> is a human-readable name used in DNS. A <strong>URL<\/strong> is the complete address that tells a client how to reach a resource.<\/p>\n<p>For example, <code>example.com<\/code> is a domain name. <code>https:\/\/example.com\/blog?v=2#dns<\/code> is a URL. The <code>example.com<\/code> part is the host&#8217;s domain; the URL also carries the scheme, path, query string, and fragment.<\/p>\n<p>This distinction becomes useful when you configure DNS, TLS certificates, redirects, and a web server. DNS resolves a hostname to an IP address or returns other record types. A URL tells the client which scheme to use and which resource to request from that host.<\/p>\n<p><strong>Start here<\/strong> &#8211; When you inspect an address, separate the host from the scheme, port, path, query string, and fragment. That small habit prevents several layers from getting mixed together.<\/p>\n<h2 id=\"what-parts-make-up-a-url\">What parts make up a URL?<\/h2>\n<p>URL syntax follows the general URI structure described in RFC 3986. A browser address can look like this:<\/p>\n<pre><code>https:\/\/user:password@www.example.com:8443\/store\/product?id=42&amp;color=blue#comments<\/code><\/pre>\n<p>Each part has its own job:<\/p>\n<table>\n<thead>\n<tr>\n<th>Part<\/th>\n<th>Example<\/th>\n<th>Purpose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Scheme<\/td>\n<td><code>https<\/code><\/td>\n<td>Specifies the protocol used for communication.<\/td>\n<\/tr>\n<tr>\n<td>User information<\/td>\n<td><code>user:password@<\/code><\/td>\n<td>Credentials that can be carried in a URL, although you should generally avoid doing this.<\/td>\n<\/tr>\n<tr>\n<td>Host<\/td>\n<td><code>www.example.com<\/code><\/td>\n<td>The server address, which may be a domain, hostname, or IP address.<\/td>\n<\/tr>\n<tr>\n<td>Port<\/td>\n<td><code>8443<\/code><\/td>\n<td>Specifies the network port used for the connection.<\/td>\n<\/tr>\n<tr>\n<td>Path<\/td>\n<td><code>\/store\/product<\/code><\/td>\n<td>The requested resource or application route.<\/td>\n<\/tr>\n<tr>\n<td>Query<\/td>\n<td><code>?id=42&amp;color=blue<\/code><\/td>\n<td>Parameters sent to the application.<\/td>\n<\/tr>\n<tr>\n<td>Fragment<\/td>\n<td><code>#comments<\/code><\/td>\n<td>A client-side location, usually a section selected in the browser.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><code>https:\/\/example.com\/<\/code> is a valid URL, and its domain is <code>example.com<\/code>. If no port is written, the client normally uses the scheme&#8217;s default port: TCP 80 for HTTP and TCP 443 for HTTPS.<\/p>\n<p>Some clients accept a username and password in a URL, but I avoid it. URLs can turn up in browser history, proxy logs, and web-server logs. Depending on the request and software involved, the URL may also appear in a referrer value.<\/p>\n<p>I made this mistake years ago while testing an internal service: I pasted a URL containing a temporary token into a support ticket. The token was short-lived, but the lesson was not. Keep credentials and secrets out of URLs.<\/p>\n<p><strong>Use instead<\/strong> &#8211; Put the site behind HTTPS and use a separate authentication mechanism for administrative access.<\/p>\n<div class=\"aiw-callout aiw-callout-tip\">\n<p class=\"aiw-callout-label\">Tip<\/p>\n<p>Read a URL from left to right: identify the scheme, isolate the host, and then inspect the port, path, query, and fragment. This prevents DNS and web-server problems from getting mixed together.<\/p>\n<\/div>\n<h2 id=\"what-is-a-domain-and-how-does-it-work\">What is a domain, and how does it work?<\/h2>\n<p>A domain is a name within the DNS hierarchy. DNS can use that name to return IPv4 and IPv6 addresses, mail destinations, verification data, aliases, and other records.<\/p>\n<p>If we split <code>www.example.com<\/code> into labels:<\/p>\n<ul>\n<li><strong>www:<\/strong> A label commonly used as a hostname or subdomain.<\/li>\n<li><strong>example:<\/strong> The second-level part of the domain name.<\/li>\n<li><strong>com:<\/strong> The top-level domain, or TLD.<\/li>\n<\/ul>\n<p>The dot to the right of the name represents the DNS root. The fully qualified form can technically be written as <code>www.example.com.<\/code>; most people leave the final dot out.<\/p>\n<p>Domain registration and web hosting are separate services. Registering a domain gives you control over the name and its delegation. A VPS or hosting account provides the infrastructure where the application and its data run.<\/p>\n<p>A working setup normally involves a registrar, authoritative nameservers, and the required DNS records. A website commonly needs an A or AAAA record, email needs an MX record, and domain verification often uses a TXT record.<\/p>\n<p><code>dig +short example.com A<\/code> displays the A record, while <code>dig +short example.com AAAA<\/code> displays the IPv6 record. Empty output may mean the record is absent or that the resolver returned no answer. It does not prove that the web server is down.<\/p>\n<p>That last distinction has saved me more than once. When a customer reported a dead website, I initially looked at Nginx logs before checking DNS. The logs were quiet because the request was never reaching the server.<\/p>\n<p><strong>Check first<\/strong> &#8211; When a site cannot be reached, inspect its A, AAAA, and CNAME records with <code>dig +short<\/code> before combining DNS and HTTP into one guess.<\/p>\n<h2 id=\"how-can-you-tell-a-domain-from-a-url\">How can you tell a domain from a URL?<\/h2>\n<p>Read the address from left to right. Identify the scheme, isolate the host, and then look at everything after the host. The host can contain a domain or a hostname under that domain. The path, query, and fragment are not part of the domain.<\/p>\n<table>\n<thead>\n<tr>\n<th>Address<\/th>\n<th>Domain or host<\/th>\n<th>Extra URL information<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>example.com<\/code><\/td>\n<td><code>example.com<\/code><\/td>\n<td>No scheme, path, or parameters are shown.<\/td>\n<\/tr>\n<tr>\n<td><code>https:\/\/example.com<\/code><\/td>\n<td><code>example.com<\/code><\/td>\n<td>The <code>https<\/code> scheme has been added.<\/td>\n<\/tr>\n<tr>\n<td><code>https:\/\/blog.example.com\/post<\/code><\/td>\n<td><code>blog.example.com<\/code><\/td>\n<td><code>\/post<\/code> is the path.<\/td>\n<\/tr>\n<tr>\n<td><code>https:\/\/example.com:8443\/app<\/code><\/td>\n<td><code>example.com<\/code><\/td>\n<td>The URL includes port 8443 and the <code>\/app<\/code> path.<\/td>\n<\/tr>\n<tr>\n<td><code>https:\/\/example.com\/product?id=8<\/code><\/td>\n<td><code>example.com<\/code><\/td>\n<td>The URL includes a path and the <code>id=8<\/code> query.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Here is the detail that often matters in production: <code>blog.example.com<\/code> and <code>example.com<\/code> may belong to the same DNS zone, but they are separate hostnames. They can have different DNS records and can point to different IP addresses.<\/p>\n<p>The same applies to <code>example.com<\/code>, <code>www.example.com<\/code>, and <code>m.example.com<\/code>. A web server, TLS certificate, and redirect rule can evaluate each one separately.<\/p>\n<p>The <code>https:\/\/<\/code> at the beginning of a URL is not the domain. It is the scheme. The domain is part of the host, while the URL describes the complete request address.<\/p>\n<p>Short version: name and address are not the same thing.<\/p>\n<h2 id=\"are-domain-hostname-and-url-the-same-thing\">Are domain, hostname, and URL the same thing?<\/h2>\n<p>They overlap, but they are not synonyms.<\/p>\n<ul>\n<li><strong>Domain:<\/strong> A name or namespace within the DNS hierarchy. Example: <code>example.com<\/code>.<\/li>\n<li><strong>Hostname:<\/strong> A name identifying a particular machine or service on a network. Example: <code>vps01.example.com<\/code>.<\/li>\n<li><strong>FQDN:<\/strong> A hostname written with its complete DNS hierarchy. With the root dot included, it is <code>vps01.example.com.<\/code>.<\/li>\n<li><strong>URL:<\/strong> An address combining a scheme, host, port, and resource path. Example: <code>https:\/\/vps01.example.com:8443\/panel<\/code>.<\/li>\n<\/ul>\n<p><code>vps01.example.com<\/code> can be a hostname. The same text can be the host portion of a URL, but it is not a complete URL until a scheme is included.<\/p>\n<p>A DNS record and a web URL belong to different layers. An A record maps a hostname to an IPv4 address. An HTTP request carries the host and path from the URL to the web server. Nginx can use the <code>Host<\/code> header to select the correct virtual server when several sites share one IP address.<\/p>\n<p>This is how several sites can live on one VPS. They may all point to the same IP, while Nginx chooses a different document root or application upstream based on the hostname.<\/p>\n<p>One warning: the <code>Host<\/code> header is not, by itself, an authentication mechanism. Your application still needs proper access control.<\/p>\n<h2 id=\"how-do-https-dns-and-redirects-relate-to-domains-and-urls\">How do HTTPS, DNS, and redirects relate to domains and URLs?<\/h2>\n<p>HTTPS is not a domain. During the TLS connection, the client validates a certificate for the hostname it selected. A certificate for <code>example.com<\/code> does not automatically cover <code>www.example.com<\/code>; the certificate must include that name or an appropriate wildcard.<\/p>\n<p>When a browser opens <code>https:\/\/example.com\/product<\/code>, the process roughly looks like this:<\/p>\n<ol>\n<li><strong>DNS resolution:<\/strong> The client looks up an A or AAAA record for <code>example.com<\/code>.<\/li>\n<li><strong>Connection:<\/strong> HTTPS normally uses TCP port 443. With HTTP\/3, QUIC can use UDP port 443.<\/li>\n<li><strong>TLS validation:<\/strong> The certificate, hostname, and validity period are checked.<\/li>\n<li><strong>HTTP request:<\/strong> The host and <code>\/product<\/code> path are sent to the server.<\/li>\n<li><strong>Application response:<\/strong> The server returns content, an error, or a redirect such as 301 or 302.<\/li>\n<\/ol>\n<p>A redirect can change the URL&#8217;s domain without changing DNS. If <code>http:\/\/example.com<\/code> redirects to <code>https:\/\/www.example.com\/<\/code> with a 301 response, the DNS record has not necessarily changed. The web server or CDN issued the redirect.<\/p>\n<p>During a domain migration, DNS caches and TTL values can cause different resolvers to return different answers for a while. Do not check only in a browser. Test the authoritative nameserver and public resolvers separately. The post <em><a href=\"https:\/\/www.vps.tc\/blog\/en\/what-is-dns-propagation-how-long-does-it-take\/\">What Is DNS Propagation? How Long Does It Take?<\/a><\/em> explains this caching behavior in more detail.<\/p>\n<p>When moving a site from HTTP to HTTPS, check the 301 redirect, canonical URL, certificate coverage, and absolute URLs generated by the application together. <em><a href=\"https:\/\/www.vps.tc\/blog\/en\/301-redirect-seo-implementation-guide\/\">What Is a 301 Redirect? An SEO Implementation Guide<\/a><\/em> covers the practical use of permanent redirects.<\/p>\n<p><strong>Test separately<\/strong> &#8211; Check the DNS answer, TLS certificate, and HTTP status code as different layers when investigating a redirect problem.<\/p>\n<div class=\"aiw-callout aiw-callout-warn\">\n<p class=\"aiw-callout-label\">Caution<\/p>\n<p>A redirect does not automatically mean that DNS changed. The DNS answer, TLS certificate, and HTTP response come from different layers and should be tested independently.<\/p>\n<\/div>\n<h2 id=\"testing-domains-and-urls-from-the-command-line\">Testing domains and URLs from the command line<\/h2>\n<p>A browser can hide the original problem with caches, extensions, and browser-specific behavior. I usually start in a terminal. It is less pretty, but the output is honest.<\/p>\n<pre><code>dig +short example.com A\ndig +short www.example.com CNAME\ncurl -I https:\/\/www.example.com\/<\/code><\/pre>\n<p>The first two commands inspect DNS records. <code>curl -I<\/code> requests only the HTTP headers. You may see status codes such as <code>HTTP\/2 200<\/code>, <code>301<\/code>, <code>302<\/code>, or <code>404<\/code>. A 301 or 302 means the request reached a server, but that server sent the client somewhere else.<\/p>\n<p>Use <code>-L<\/code> to follow and display a redirect chain:<\/p>\n<pre><code>curl -IL https:\/\/example.com\/<\/code><\/pre>\n<p>This shows the headers from each redirect step. Two or three unnecessary redirects add latency and can cause cookie or canonical-URL problems in some applications.<\/p>\n<p>To see which resolver is answering:<\/p>\n<pre><code>dig example.com A\ndig @1.1.1.1 example.com A\ndig @8.8.8.8 example.com A<\/code><\/pre>\n<p>The first query uses the resolver configured on your system. The other two query specific public resolvers. If the answers differ, inspect TTL, cached data, and the authoritative nameserver configuration. <code>dig +short<\/code> is easier to read; for deeper troubleshooting, keep the full output.<\/p>\n<p>You can also test a hostname against a specific IP while preserving the hostname used for TLS and HTTP:<\/p>\n<pre><code>curl --resolve example.com:443:203.0.113.10 -I https:\/\/example.com\/<\/code><\/pre>\n<p><code>--resolve<\/code> creates a temporary IP mapping for the specified host and port. The request still uses <code>example.com<\/code>, which makes it useful for testing a staging IP without changing public DNS.<\/p>\n<p>I keep a similar command ready when testing changes in my Proxmox lab. It has saved me from changing DNS just to discover that the Nginx virtual-host rule was the real problem. I once changed the wrong test record anyway, because I copied the hostname from an old note instead of checking it with <code>hostname<\/code>. The command was correct; my target was not.<\/p>\n<p><strong>My order<\/strong> &#8211; Check DNS with <code>dig<\/code>, then verify HTTP and redirects with <code>curl -I<\/code>.<\/p>\n<div class=\"aiw-callout aiw-callout-field\">\n<p class=\"aiw-callout-label\">From the field<\/p>\n<p>I used curl &#8211;resolve in my Proxmox lab to test a staging IP while preserving the real hostname for TLS and HTTP. It was cleaner than changing public DNS and waiting for caches to expire.<\/p>\n<\/div>\n<h2 id=\"common-domain-and-url-mistakes\">Common domain and URL mistakes<\/h2>\n<p>One frequent mistake is treating the path as part of the domain. In <code>example.com\/blog<\/code>, the domain is <code>example.com<\/code> and the path is <code>\/blog<\/code>. DNS does not receive <code>\/blog<\/code>; it resolves only the host.<\/p>\n<p>Another mistake is assuming that <code>www<\/code> and the apex domain are automatically identical. A CNAME may exist for <code>www.example.com<\/code>, while <code>example.com<\/code> needs its own A or suitable provider-specific record. A CNAME at the apex depends on support for mechanisms such as ALIAS or ANAME.<\/p>\n<p>A third mistake is treating query parameters as access control. A URL such as <code>\/download?file=report.pdf<\/code> does not authorize anyone to download the file. The application still needs session and permission checks.<\/p>\n<p>A fourth mistake is ignoring URL encoding. Spaces, non-ASCII characters, and special characters such as <code>&amp;<\/code> must be encoded correctly. The form shown in a browser&#8217;s address bar may not be identical to the form parsed by the application.<\/p>\n<p>A fifth mistake is treating <code>http<\/code> and <code>https<\/code> as the same origin. An origin is defined by the scheme, host, and port. <code>https:\/\/example.com<\/code> and <code>http:\/\/example.com<\/code> differ by more than one character: their encryption and browser security behavior are different.<\/p>\n<p>With a CDN, the URL can remain unchanged while DNS returns a CDN edge IP. As explained in <em><a href=\"https:\/\/www.vps.tc\/blog\/en\/what-is-a-cdn-how-it-speeds-up-websites\/\">What Is a CDN? How It Speeds Up Websites<\/a><\/em>, adding a distribution layer between the visitor and the origin changes the request path, not the meaning of the domain.<\/p>\n<p>Do not fix these problems with a broad rewrite rule or a quick <code>chmod 777<\/code>. That only changes the symptom, and sometimes creates a new problem.<\/p>\n<div class=\"aiw-callout aiw-callout-example\">\n<p class=\"aiw-callout-label\">Example<\/p>\n<p>In example.com\/blog, DNS resolves example.com and knows nothing about \/blog. The path is interpreted only after an HTTP request reaches the web server.<\/p>\n<\/div>\n<h2 id=\"a-short-decision-table-for-domains-and-urls\">A short decision table for domains and URLs<\/h2>\n<p>This table is a quick way to decide which layer deserves your attention:<\/p>\n<table>\n<thead>\n<tr>\n<th>Question<\/th>\n<th>Concept to inspect<\/th>\n<th>Example<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Is the name registered?<\/td>\n<td>Domain<\/td>\n<td><code>example.com<\/code><\/td>\n<\/tr>\n<tr>\n<td>Which IP does it resolve to?<\/td>\n<td>DNS record<\/td>\n<td><code>A<\/code> or <code>AAAA<\/code><\/td>\n<\/tr>\n<tr>\n<td>Which protocol is used?<\/td>\n<td>URL scheme<\/td>\n<td><code>https:\/\/<\/code><\/td>\n<\/tr>\n<tr>\n<td>Which page or API route is requested?<\/td>\n<td>URL path<\/td>\n<td><code>\/api\/users<\/code><\/td>\n<\/tr>\n<tr>\n<td>Which filter is sent?<\/td>\n<td>Query string<\/td>\n<td><code>?page=2<\/code><\/td>\n<\/tr>\n<tr>\n<td>Which section should open?<\/td>\n<td>Fragment<\/td>\n<td><code>#comments<\/code><\/td>\n<\/tr>\n<tr>\n<td>Which application should receive it?<\/td>\n<td>Host and web-server rule<\/td>\n<td><code>api.example.com<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>The short version is this: a domain is the named part of a URL&#8217;s host, while a URL is the complete address describing how to reach a resource on that host. Not every domain is a URL. A URL also does not need a registered domain; it can use an IP address or <code>localhost<\/code>.<\/p>\n<p>For example, <code>http:\/\/127.0.0.1:8080\/test<\/code> is a valid URL, but it contains no registered domain. Its host is an IPv4 address. Likewise, <code>file:\/\/\/home\/user\/notes.txt<\/code> is a URL form without a web domain.<\/p>\n<p><strong>Keep this habit<\/strong> &#8211; Use &#8220;domain&#8221; for the name itself and &#8220;URL&#8221; for the complete address, including its scheme and resource path. When a site misbehaves, inspect those pieces one at a time.<\/p>\n<h2 id=\"check-these-before-troubleshooting\">Check These Before Troubleshooting<\/h2>\n<ul class=\"aiw-checklist\">\n<li>Separate the domain or hostname from the complete URL.<\/li>\n<li>Check A, AAAA, and CNAME records with dig.<\/li>\n<li>Confirm the URL scheme and port.<\/li>\n<li>Verify that the TLS certificate covers the requested hostname.<\/li>\n<li>Inspect HTTP status codes with curl -I.<\/li>\n<li>Follow redirect chains with curl -IL.<\/li>\n<li>Test a staging IP with curl &#8211;resolve before changing public DNS.<\/li>\n<\/ul>\n<div class=\"aiw-cta\">\n<p>Keep the layers separate: domain and DNS first, then TLS, HTTP, redirects, and application paths. The next time an address looks suspicious, read it one component at a time instead of treating the whole string as a single name.<\/p>\n<p class=\"aiw-cta-action\"><a href=\"https:\/\/www.vps.tc\/en\/vps\">Explore VPS plans<\/a><\/p>\n<\/div>\n<h2 id=\"frequently-asked-questions\">Frequently Asked Questions<\/h2>\n<div class=\"aiw-faq\">\n<details class=\"aiw-faq-item\" open>\n<summary>Is a domain the same as a URL?<\/summary>\n<p>No. A domain is a human-readable name in the DNS hierarchy, such as example.com. A URL is a complete resource address, such as https:\/\/example.com\/docs. It can include the scheme, host, port, path, query parameters, and fragment. The domain may be one part of a URL, but the two terms describe different things.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Is www.example.com a domain or a URL?<\/summary>\n<p>Without a scheme, www.example.com is a hostname or domain name used in DNS, not a complete URL. Add a scheme and it becomes a URL: https:\/\/www.example.com\/. The www label is commonly configured as a subdomain or hostname, and it may have a different DNS record, TLS coverage, or web-server rule from example.com.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Does DNS resolve the complete URL?<\/summary>\n<p>No. DNS resolves the host name, not the path or query string. For https:\/\/example.com\/store?id=4, DNS looks up example.com. The \/store path and id=4 query are sent later in the HTTP request. This is why adding or removing a URL path does not require a separate DNS record.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Can a URL exist without a domain?<\/summary>\n<p>Yes. A URL can use an IPv4 address, IPv6 address, localhost, or a local file path instead of a registered domain. For example, http:\/\/127.0.0.1:8080\/test is a valid URL whose host is an IP address. The file:\/\/\/home\/user\/notes.txt form is also a URL, but it does not identify a web domain.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Why can example.com and www.example.com behave differently?<\/summary>\n<p>They are different hostnames, even when they belong to the same DNS zone or point to the same IP address. DNS records, TLS certificates, Nginx virtual-host rules, cookies, and redirects can treat them separately. If one works and the other fails, inspect the DNS record, certificate names, and web-server configuration for each hostname.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>What is the best way to troubleshoot a domain or URL problem?<\/summary>\n<p>Test each layer separately. Use dig to inspect DNS records and compare resolvers when necessary. Use curl -I to inspect the HTTP response, curl -IL to follow redirects, and curl &#8211;resolve to test a specific IP while preserving the hostname. For HTTPS problems, also verify that the certificate covers the exact hostname in the URL.<\/p>\n<\/details>\n<\/div>\n<h2 id=\"sources\">Sources<\/h2>\n<ul class=\"aiw-sources\">\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc3986\" target=\"_blank\" rel=\"noopener\">IETF RFC 3986 &#8211; Uniform Resource Identifier Syntax<\/a> \u2014 rfc-editor.org<\/li>\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc9110\" target=\"_blank\" rel=\"noopener\">IETF RFC 9110 &#8211; HTTP Semantics<\/a> \u2014 rfc-editor.org<\/li>\n<li><a href=\"https:\/\/www.icann.org\/resources\/pages\/glossary-2014-02-03-en\" target=\"_blank\" rel=\"noopener\">ICANN &#8211; Domain Name System Glossary<\/a> \u2014 icann.org<\/li>\n<li><a href=\"https:\/\/www.iana.org\/assignments\/service-names-port-numbers\/service-names-port-numbers.xhtml\" target=\"_blank\" rel=\"noopener\">IANA &#8211; Service Name and Transport Protocol Port Number Registry<\/a> \u2014 iana.org<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>A domain is a human-readable DNS name; a URL is the complete address that identifies how to reach a specific resource.<\/p>\n","protected":false},"author":2,"featured_media":1016,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1018","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-domain"],"lang":"en","translations":{"en":1018,"tr":1017},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/1018","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/comments?post=1018"}],"version-history":[{"count":1,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/1018\/revisions"}],"predecessor-version":[{"id":1020,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/1018\/revisions\/1020"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media\/1016"}],"wp:attachment":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media?parent=1018"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/categories?post=1018"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/tags?post=1018"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}