What causes Curl error 6 (could not resolve host) from UnityWebRequest?

DNS resolution for the request URL failed on the player's machine — a typo in the URL, no network connectivity, a captive portal, IPv6-only networks, or the player's DNS blocking your domain.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix “Curl error 6: Could not resolve host” in UnityWebRequest

Quick answer: Validate the URL, distinguish connection errors from HTTP errors via result == UnityWebRequest.Result.ConnectionError, retry with backoff, and degrade gracefully when the network is unavailable.

This error means the hostname in your request never resolved to an IP — the request never left DNS. In shipped games it is usually the player's network, not your server. Here is how to handle it robustly.

How to fix it

1. Rule out the URL first

Log the exact URL at request time — a missing https://, an interpolated empty string, or a stale config pointing at a dead domain all produce error 6 on every machine.

2. Branch on the result type

Check request.result: ConnectionError (DNS, offline, timeouts) should retry with exponential backoff; ProtocolError (4xx/5xx) should not — the server answered.

3. Expect captive portals and offline players

Test on a network behind a login page and with Wi-Fi off. Your game should queue or skip non-critical requests, never block play on them.

4. Track the failure rate remotely

Report connection failures with the player's platform and error code so you can tell a broken CDN config (everyone fails) from individual network issues (a trickle).

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every Unity error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Reproduce it once with full context and the fix writes itself. The hunt is the expensive part.