Skip to content
Link Me.

Practical guide About 4 min read

Connect a custom domain and check the complete visitor journey

Understand routing, administrator approval, HTTPS, and CAPTCHA hostname settings when publishing links on your own domain.

Use a hostname you can maintain

A custom hostname, such as go.example.com, gives your short links an address associated with your organization. Use a dedicated subdomain whose DNS you can manage and whose registration will stay active. That separates short links from an existing website. Write down who controls the domain, who manages DNS, and who can change the hosting configuration.

Submitting a hostname in the domain settings does not finish the connection. Follow its connection guide, including the TXT ownership record if one is shown, then wait for administrator approval. The service's provisioning agent configures routing and HTTPS after approval. The domain becomes selectable on link forms when its status is Active. A DNS result on its own is not a substitute for approval.

Change the specific DNS record, then inspect the public result

For a subdomain, a CNAME commonly points the chosen name at the service hostname. An A record points to an IPv4 address; an AAAA record points to an IPv6 address. Use the record type and target supplied for your deployment. If the guide supplies a TXT ownership record, publish its exact name and value and keep it until the domain is Active. Avoid leaving conflicting records at the same name, and check that an old IPv6 address is not still directing part of the audience to another server.

You can usually keep the DNS provider that already serves your domain. Changing nameservers changes who answers for the zone and can affect other records, including mail. The nameserver information shown by this service is a separate diagnostic; it does not replace the routing records or a certificate. DNS caches can continue returning an older answer after a change, so compare the public result with the settings you intended to publish.

Routing and HTTPS must agree

DNS brings a request to a server, but the server must also recognize the hostname. For approved custom domains, the provisioning agent creates the host configuration, requests a trusted certificate for that name, and activates HTTPS with an HTTP redirect. You do not need to add each custom domain as a CloudPanel alias or manually request its certificate. The primary service hostname and certificate remain the administrator's responsibility in CloudPanel. The provisioning status helps distinguish a routing problem from a certificate or activation problem.

Certificate issuance can fail if the validation request cannot reach the expected server. Review public routing, port access, proxy settings, and the certificate agent's logs with the administrator. If a browser reports an unrecognized TLS name or a certificate mismatch, check the host configuration and certificate rather than repeatedly changing the short link. Do not bypass certificate verification to declare the setup complete.

  • Check the exact hostname, including any subdomain.
  • Test both the short link and its final destination over HTTPS.
  • Keep domain renewal and certificate maintenance assigned to someone.

Authorize the hostname with your CAPTCHA provider

If a link shows an external CAPTCHA, its site key must be allowed to operate on the hostname where the challenge appears. A key configured for the primary service address may need additional hostname authorization before it works on go.example.com. That authorization belongs in the CAPTCHA provider's settings. The destination website's hostname is a different origin and is not the hostname serving this challenge.

Check that the selected key, provider, and server-side secret belong together. Keep the secret in the site's protected configuration; never put it in a public URL, screenshot, or support message. A locally generated challenge is a separate option, so do not assume that selecting another challenge method repairs an external provider's hostname restrictions.

Test as a visitor, then keep the connection healthy

Create a test link with an ordinary public destination and open its complete custom-domain URL in a signed-out browser. If a gate is enabled, finish it and confirm that the intended page opens. Repeat on a second device or network when practical. This checks the whole journey, including DNS, HTTPS, the gate, and the redirect, rather than only one green status indicator.

Record the working setup before changing DNS or hosting again. When a link stops working, note the hostname, the approximate time, and the stage that failed. Those details help an administrator inspect the right logs without exposing secrets. Continue reviewing important custom-domain links after hosting changes and domain renewals; a correct initial connection still needs maintenance.