WordPress “A valid URL was not provided.” Error and /etc/hosts Loopback Issue

Introduction

If you’ve ever dealt with a WordPress site, you’ve probably hit a wall with cryptic errors. I found this particular nightmare—the vague “A valid URL was not provided.” error—while debugging a failed wp_safe_remote_post request using the amazing HTTP Requests Manager plugin.

The confusing part? The URL was perfectly fine! The problem isn’t a typo, but a clash between a core WordPress security feature and how your server resolves your own domain name.

The Error and Symptom

This issue typically manifests when a plugin tries to make an internal HTTP request—often from a main site to a subdomain or a different part of the same platform—using a function like wp_safe_remote_post().

The Debug Log Output (Sanitized)

Here is a sanitized version of the typical error output you might see in your debug logs or network request failure details:

Request: [0.002s]
Error: A valid URL was not provided. plugin: [Remote Sync Plugin]
Page: [https://example.com/wp-admin/admin-ajax.php](https://example.com/wp-admin/admin-ajax.php)
ajax_action: wprus_login_notify_ping_remote

Request Details
{
  "method": "POST",
  "user-agent": "WordPress/6.8.3; [https://example.com](https://example.com)",
  "reject_unsafe_urls": true,
  "request_url_original": "[https://subdomain.example.com/api/login/](https://subdomain.example.com/api/login/)",
  // ... other details
}

Response
{
  "errors": {
    "http_request_failed": [
      "A valid URL was not provided."
    ]
  },
  "error_data": []
}

The key problem here is that the URL, https://subdomain.example.com/api/login/, looks perfectly valid, yet WordPress rejects it.

The Root Cause: The /etc/hosts File

The core problem lies in the interaction between a common server optimization technique and WordPress’s robust defense against Server-Side Request Forgery (SSRF) attacks.

Server Configuration Issue

Many modern hosting/server management solutions (including some well-known providers) add entries to the local server’s /etc/hosts file for performance or routing purposes. These entries often look like this:

# GridPane Sites (Example)
127.0.0.1 example.com [www.example.com](https://www.example.com)
127.0.0.1 subdomain.example.com

When the WordPress HTTP client tries to make an outbound request to subdomain.example.com, the server checks its local /etc/hosts file first, which tells it that the domain resolves to 127.0.0.1 (the loopback address).

The WordPress Security Block

WordPress uses the function wp_http_validate_url() to check if a URL is “safe” before making a remote request (especially when using wp_safe_remote_get()/post(), which sets reject_unsafe_urls to true).

Inside this function, WordPress checks the IP address to see if it is a private or reserved IP, including 127.0.0.1.

// Snippet from wp-includes/http.php (simplified)
if ( $ip ) {
    $parts = array_map( 'intval', explode( '.', $ip ) );
    
    // Check for loopback (127.x.x.x) and private IPs
    if ( 127 === $parts[0] || 10 === $parts[0] || 0 === $parts[0]
        || ( 172 === $parts[0] && 16 <= $parts[1] && 31 >= $parts[1] )
        || ( 192 === $parts[0] && 168 === $parts[1] )
    ) {
        // If host appears local, reject unless specifically allowed.
        if ( ! apply_filters( 'http_request_host_is_external', false, $host, $url ) ) {
            return false; // URL is rejected!
        }
    }
}

Resolution

Remove anything within the /etc/hosts file that points your domain name to 127.0.0.1, if you’re on GridPane then you can comment out the /etc/hosts line.