I changed the nameserver in Gabia but the site still won't load. How long do I wait?

A nameserver change is the slow kind of DNS change — it has to be published by the registry and then picked up by resolvers all over the world, which commonly takes up to 24–48 hours. That is genuinely different from editing an A record inside a zone you already control, which is usually live in minutes. So before you count hours, decide which change you actually made. If you switched the domain's NS records (for example from Gabia's default nameservers to an external DNS provider, or the other way around), expect up to two days and confirm the authoritative NS has actually flipped. If you only edited a record in My Gabia's DNS tool and it's been more than an hour, the delegation isn't your problem — something else is, and more waiting won't fix it.

Why do my record edits in My Gabia's DNS tool have no effect?

Because Gabia's DNS tool only controls a domain that is actually delegated to Gabia's nameservers (the ns.gabia.co.kr set). Gabia is Korea's largest registrar, so a very common setup is: you registered the domain at Gabia but later delegated DNS to an external provider — Cloudflare, AWS Route 53, your host — by changing the NS records. Once you do that, the external provider is authoritative, and your edits in Gabia's DNS tool change a zone that nobody queries. Read the domain's live NS records first: whoever they point to is the only place your edits will take effect.

It works for me but a colleague still sees the old page. Did the change fail?

Almost certainly not. This is stale and negative caching, not a broken change. When a name resolved to an old address (or failed to resolve), resolvers remember that answer for the length of the record's TTL, and a colleague on another network — or a phone on mobile data — can still be inside that cached window while your resolver has already refreshed. Check the record from several resolvers at once: if they now agree on the correct answer, you're done and just waiting out old caches; if they disagree, you're mid-propagation, not broken. Either way, changing more settings now only adds new caches to wait on.

Gabia Domain Not Connecting? Fix Nameservers & DNS

Problem

You registered a domain at Gabia, pointed it where it needs to go, and the site still won’t load — a timeout, a “server not found,” or the old parking page instead of your content. The domain clearly exists; you can see it in your Gabia account. What’s broken is one specific layer in the chain between owning a name and having it answer with the right address, and with Gabia the usual trap is that the registrar and the DNS host can be the same company or two different ones — and you edited the wrong one.

Symptoms

The domain resolves to nothing (NXDOMAIN / “server not found”) or times out in the browser.
It loads Gabia’s parking page, an old site, or a host’s default page instead of yours.
You changed the nameserver and nothing happened — hours later it still won’t connect.
Record edits in My Gabia’s DNS tool (DNS 관리툴) have no visible effect.
It works on one network but not another, or for you but not a colleague.

The Three Layers That Have to Agree

A domain connecting is not one setting. It’s three layers stacked on top of each other, and a “not connecting” problem is almost always a mismatch between them. Gabia muddies this because it plays two roles — registrar and DNS host — so the first thing to get straight is which role you’re actually configuring.

Layer 1 — the registrar (who owns the name). This is the Gabia account that holds the registration. Its one job that matters here is pointing the domain’s nameserver (NS) records at whoever will answer DNS queries. By default that’s Gabia’s own nameservers (the ns.gabia.co.kr set). If you want an external provider to run DNS, this is where you change the NS — and that change takes roughly 24–48 hours.

Layer 2 — the nameserver (who answers). Whatever the NS records point to is the authority for your domain. This is the layer people get wrong: a DNS panel only controls the domain if that panel’s nameservers are the ones in the NS records. If your NS still points at Gabia but you’re editing records at Cloudflare — or the reverse — the authoritative answers keep coming from the other side, and your edits do nothing.

Layer 3 — the DNS records (what the answer says). Once the right nameserver is authoritative, the A record (or CNAME) is the actual address the name resolves to. This is the fast layer: a corrected record inside the authoritative zone is usually live in minutes, not days.

The single most common Gabia mistake is confusing Layer 1 and Layer 2 — leaving the domain delegated to Gabia’s nameservers while editing records somewhere else (or delegating it away and then still editing in My Gabia). Either way you wait for a change that will never appear, because it’s being made in a zone nobody is asking.

Top 3 Causes

Editing records in a zone that isn’t authoritative. You’re changing A/CNAME records in My Gabia, but the domain’s NS points at an external provider (or you moved DNS out and kept editing in Gabia). The tell: your edits have no effect, and the live NS records aren’t the ones you think they are.
A nameserver change that simply hasn’t propagated. You correctly switched the NS (to or from Gabia), but you’re inside the 24–48h delegation window. The tell: resolvers disagree about which nameserver is authoritative, or the old NS still shows.
A missing/wrong record, or caching after a fix. The nameserver is right but the A record is absent, points at the wrong IP, or you fixed it and a stale/negative cache is still serving the old answer. The tell: the authoritative nameserver returns the wrong record — or the right one, while some resolvers still serve the old value.

One note on values: use the exact record values your host or platform shows you in its own console — IPs and CNAME targets change, and a number copied from a three-year-old blog post is how a correct-looking setup quietly fails. The layers below tell you where to put the record; the host tells you what it should be.

Diagnose with DechoNet

DNS Lookup shows the domain’s current NS records and its A/CNAME answers, so you can confirm which nameserver is authoritative and what it actually returns — the fastest way to catch a Layer 1/Layer 2 mismatch where you’re editing the wrong zone.
DNS Propagation Check queries resolvers around the world at once. If they disagree, you’re mid-propagation after a nameserver or record change; if they agree on a wrong answer, propagation is finished and the record itself is the problem.

Resolution Checklist

Run DNS Lookup and read the NS records first — confirm whether the domain is delegated to Gabia (ns.gabia.co.kr set) or to an external provider.
Edit records only in the DNS panel of whoever the NS actually points to. If that’s Gabia, use My Gabia’s DNS tool; if it’s an external provider, edit there.
If the NS itself is wrong, change it at Gabia (the registrar), then expect 24–48 hours before it takes effect — don’t touch records in the meantime.
Confirm the A record points at the correct server IP (or the CNAME at the correct target) using the exact value your host shows, with no leftover parking/old-host record.
Use DNS Propagation Check across multiple resolvers; if they disagree, wait out the TTL rather than changing anything else.
If it resolves correctly but still won’t load, DNS is done — check whether the server is actually answering on that IP with an HTTP check.

When to Escalate

If DNS resolves to the correct IP everywhere but the site still won’t load, the problem has left DNS entirely — it’s the web server or hosting on that IP, not the domain connection.
If the domain resolves fine but is unreachable only from inside Korea, rule out an administrative block (the Korea Communications Standards Commission can order access blocking) before assuming a DNS fault — that’s a separate process, not a records change.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.