According to the guidelines set by the W3C Spec, there is no method available to differentiate between a failed network connection and a failed CORS exchange.

The CORS specification outlines the procedure for a simple cross-origin request, emphasizing steps to be followed during the request process:

Execute the necessary steps for making a request while adhering to the specified rules.

In scenarios where the manual redirect flag remains unset and a response with HTTP status codes 301, 302, 303, 307, or 308 is received: Implement the redirect actions.

If the request is canceled by the end user: Initiate the abort protocol.

In cases of network errors: In situations involving DNS issues, TLS negotiation failures, or other network-related errors, follow the prescribed network error response. Avoid any form of end user interaction...

In all other instances: Conduct a comprehensive resource sharing assessment. If unsuccessful, resort to the network error procedures...

In instances of either a futile network connection or an unsuccessful CORS interchange, the guidelines detailed in the network error steps are executed, leading to an indistinguishable outcome between the two scenarios.

Why is this approach essential? It serves as a protective measure against potential threats seeking to analyze the LAN's network topology. For instance, a malevolent script on a webpage could extract your router's IP address through an HTTP interface request, gaining insights into your network configuration (such as the size of your private IP block - whether it is a /8 or a /16). As routers typically do not transmit CORS headers, this strategy ensures that the script acquires no sensitive details whatsoever.

Here's an alternative method that may assist some individuals. It involves a workaround for dealing with the difference between CORS and network errors, specifically in Chrome or Firefox (although it's not a foolproof solution).

var external = 'your url';

if (window.fetch) {
    // This code block is for browsers like Chrome or Firefox which support native fetch
    fetch(external, {'mode':'no-cors'})
        .then(function () {
            // The external URL is reachable but fails due to CORS restrictions
            // Fetch will still trigger if it's a CORS error
        })
        .catch(function () {
            // The external URL is not reachable
        });
} else {
    // For non-updated Safari or older versions of IE...
    // Error type detection in this case is unknown
}

To distinguish a CORS violation from other failed AJAX requests, you can examine the response headers of a HEAD request using server-side code and send back the findings to your client page. For instance, if the AJAX request fails (status 0), you could utilize this script (let's name it cors.php) to check if the response headers contain Access-Control-* headers.

Examples:

cors.php?url=http://ip.jsontest.com
cors.php?url=http://www.google.com
cors.php?url=http://10.0.0.1

result

HTTP/1.1 200 OK Access-Control-Allow-Origin: *
HTTP/1.1 302 Found
Invalid request

cors.php - Modify as necessary

<?php /* cors.php */
$url = $_GET["url"];
if(isset($url)) {
    $headers = getHeaders($url);
    header("Access-Control-Allow-Origin: *");

    if(count($headers) == 0) {
        die("Invalid request"); // No headers returned on bad URLs
    } else {
        echo $headers[0];       // Output the HTTP status code
    }

    // Include any CORS headers
    foreach($headers as $header) {
        if(strpos($header, "Access-Control") !== false) {
            echo " " . $header;
        }
    }
}

function getHeaders($url, $needle = false) {
    $headers = array();
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 4);        // Timeout in seconds
    curl_setopt($ch, CURLOPT_TIMEOUT, 4);               // Timeout in seconds
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_VERBOSE, true);
    curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD');    // HEAD request only
    curl_setopt($ch, CURLOPT_HEADER, true);
    curl_setopt($ch, CURLOPT_HEADERFUNCTION, function($curl, $header) use(&$headers) {
        array_push($headers, $header);
        return strlen($header);
    });
    curl_exec($ch);
    return $headers;
} /* Drakes, 2015 */

Client-side test harness:

function testCORS(url, $elem) {
    $.ajax({
      url: url,
      timeout: 4000
    })
    .fail(function(jqXHR, textStatus) {
       if(jqXHR.status === 0) {
           // Check for CORS violation
           $.ajax({
              context: url,
              url: "http://myserver.com/cors.php?url=" + escape(this.url),
           })
           .done(function(msg) {
              if(msg.indexOf("HTTP") < 0) {
                $elem.text(url + " - doesn't exist or timed out");
              } else if(msg.indexOf("Access-Control-Allow-Origin") >= 0) {
                $elem.text(url + " - CORS violation because '" + msg + "'");
              } else {
                $elem.text(url + " - no Access-Control-Allow-Origin header set");
              }
           });
       } else {
           // Some other failure (e.g. 404), not related to CORS
           $elem.text(url + " - failed because '" + responseText + "'");
       }
    })
    .done(function(msg) {
      // Successful ajax request
      $elem.text(this.url + " - OK");
    }); /* Drakes, 2015 */
}

Harness driver:

// Create a div and append the results of the URL calls
$div = $("<div>");
$("body").append($div);

var urls = ["http://ip.jsontest.com", "http://google.com", "http://10.0.0.1"];
urls.map( function(url) {
   testCORS(url, $div.append("<h4>").children().last());
});

The outcomes:

http://ip.jsontest.com - OK

http://google.com - no Access-Control-Allow-Origin header set

http://10.0.0.1 - doesn't exist or timed out

Interestingly, there is a way to achieve this for images (and perhaps a similar solution exists for other specific content types). It seems that <img> tags do not abide by CORS rules, leading to the scenario where the statement "url fails to load by XHR && url succeeds to load by img src" suggests that the URL is actually working but being blocked by CORS restrictions.

While this method may not be effective in all situations, it can be useful in certain cases (such as confirming proper CORS configuration). For instance, I needed to trigger a warning in the console if my app (which has separate frontend and backend components) was installed with the backend URL correctly configured but had improper CORS settings on the server. In this scenario, using an image served as the perfect test.

function testCors(url) {
    var myRequest = new XMLHttpRequest();
    myRequest.open('GET', url, true);
    myRequest.onreadystatechange = () => {
        if (myRequest.readyState !== 4) {
            return;
        }
        if (myRequest.status === 200) {
            console.log(url, 'ok');
        } else {
            var myImage = document.createElement('img');
            myImage.onerror = (...args) => {console.log(url, 'other type of error', args);}
            myImage.onload = () => {console.log(url, 'image exists but cors blocked');}
            myImage.src = url;
            console.log(url, 'Image not found');
        }
    };
    myRequest.send();
}

In order to address the issue at hand, I devised a solution that requires modifications on the remote server by adding a new page.

1. To begin, I created a probe.html page designed to be displayed within an iframe on the remote server where CORS communication is needed.
2. Next, I implemented a window.onmessage event handler in my own page.
3. I then loaded the probe.html page onto my page using a secure iframe element.
4. Upon the iframe's onload event in my page, I transmitted a message to the iframe utilizing the window.postMessage() method.
5. The probe.html page conducts checks on the URL from the same origin within the iframe and relays back the xhr.status along with xhr.statusText response details using window.postMessage().
6. If an error status is detected, it logs the status and statusText information to our logging service for further analysis.

It is important to note that ensuring security can be challenging when passing parameters bidirectionally (as anyone can embed your iframe or manipulate postMessage events).

While this approach may not be foolproof and is limited in detecting transient errors, it does provide valuable insights into error causes, particularly useful in scenarios where direct access to users' browsers is not feasible.

Moreover, contrasting the suggested PHP solution wherein servers communicate directly, my method offers a more targeted approach to diagnosing communication failures without exposing the server to potential vulnerabilities through PHP's curl function.