1 Introduction

In my previous active-active architecture deployment practice (see details:Home Data Center Series: WordPress Active-Active Architecture (Simplified Version) Implementation Plan in Personal Blog), Cloudflare's Health Checks were one of the core mechanisms for determining node availability. Previously, the health check content of my blog was as follows:

The check path used in the image above is “/healthcheck”, which is a WordPress page I specially created. The content is very simple, only outputting an “OK” text, making it easy for Cloudflare to periodically initiate HTTP requests to confirm if the site is alive:

At the same time, I also configured policies in Cloudflare's rules for this path to bypass cache, firewalls, security challenges, etc., to ensure as much as possible that the response results truly reflect the status of the origin server.

This solution is functionally feasible and indeed ran stably for a period of time. However, during further analysis and optimization, I found that this approach actually has quite a fewhidden structural issues：

• First, this path returns a 200 status code and contains body content. Although the response body is very small, it is essentially still a complete WordPress loading process. The server still needs to go through routing resolution, plugin loading, template rendering, and other steps, which is not lightweight enough.
• Secondly, this is an “artificially constructed” page path, and WordPress itself has no built-in semantics for it. In the future, if the site structure changes or routes are rewritten, it is easy to cause the path to fail due to oversight, but Cloudflare will not immediately perceive this anomaly.
• Most importantly, because this path returns a 200 status code, even if WordPress encounters a serious internal error (such as a plugin triggering a PHP error), as long as it does not explicitly throw a 5xx, Cloudflare's health check will still determine it as “successful”. This can lead to a “false positive” — seemingly available, but actually down.

In addition, because it is a WordPress page, this solution is also inevitably subject to WordPress's own runtime mechanism and plugin intervention, further increasing uncertainty:

• The page is ultimately controlled by WordPress's front-end routing. Even if your page has no body content, WordPress will still load all plugins, theme hooks, and routing logic, unnecessarily driving up performance overhead.
• SEO plugins like Rank Mathwill automatically inject structured data (such as JSON-LD) into the page. Even if your page has no body, it might still add a large amount of schema data in the <head> section. This content is useless for health checks and instead increases the response size.
• Even if you have enabled cache bypass rules, Cloudflare APO or certain plugin caches may still “secretly cache” the page response, especially in edge scenarios where certain paths or parameters miss the rules, causing the check results to fail to truly reflect the origin server's status.

In summary, although this “using a page to simulate health checks” solution is simple and intuitive, it cannot completely bypass WordPress's internal runtime mechanisms, and there are still many uncontrollable factors. Especially in complex deployment scenarios involving active-active, high availability, and CDN acceleration,such solutions are more likely to misjudge service status due to cache interference, plugin injection, or routing failure, and are not an ideal long-term solution.

2 Source of Inspiration

Originally, even though using a custom page for health checks has some minor flaws, overall it was still usable. With my lazy personality, I wouldn't have gone out of my way to research new methods.

However, I later accidentally discovered that many software programs, such as Shadowsocks, use this URL when conducting availability tests on various nodes: ”http://www.gstatic.com/generate_204“:

This got me a bit interested. Why do all these software programs use ”http://www.gstatic.com/generate_204“ as their test link? What is so special about it that makes so many tools use it as the standard for “determining whether the network is clear”?

So I looked into the background of this address and was surprised to find that this link is not a temporary product of some obscure site, but a “no content” probe interface specially designed by Google for Android network status detection. Its response is extremely “clean” — it does not redirect, carries no body, does not trigger caching, and is not hijacked by ISPs (at least in many regions). The response code is fixed at 204 No Content, with absolutely no extra overhead. It is purely “if you reached this address, it means you can connect to the internet.”

Compared to the “health check” page I originally created myself/healthcheck, this method is obviously lighter, faster, more standardized, and harder for ISPs to tamper with or pollute.

More importantly, it inspired an idea: since Google can make such an almost “perfect” network probe endpoint, could I simulate this generate_204 response logic and deploy it on different nodes of my blog (not necessarily bound to an actual page) to serve as a unified probe endpoint forCloudflare's Health Checksto use?

3 Building my blog's generate_204: Conceptualizing the implementation idea

According to the analysis earlier in the article, to implement the generate_204 response logic on my blog, WordPress's built-in "posts" and "pages" are not suitable. The main problem is that they are naturally designed for human visitors rather than network probing programs, especially with inherent limitations in rewrite rules, URL matching, and response body control.

So, what other more suitable paths are there to choose from?

I have roughly outlined three possible implementation methods:

1. Site-level processing method：

That is, bypassing WordPress and directly handling the /generate_204 path at the Web Server layer. The biggest advantage of this method is good performance and high independence, but it also means breaking away from WordPress's unified management system. For blog environments that rely on plugin automation and unified configuration, this fragmented management method has a high maintenance cost and is not flexible enough for future expansion.

2. Theme-level logic injection：

Injecting logic into the current theme's functions.php or other Hook points to identify and respond to /generate_204 requests. This method has good adaptability and can also benefit from WordPress environment variables. However, I maintain a minimalist attitude towards theme maintenance and do not want these functional logics to clutter the theme, so I did not adopt it.

3. REST API route registration (plugin method)：

By using a WordPress plugin to add a responsive pseudo-page path (such as /generate_204). The plugin registers a custom REST API route and listens for requests on that path, returning a customized response directly when a request arrives. This method not only aligns with WordPress's extension mechanism but also keeps the code structure clear and single-responsibility, making it easy to manage and maintain. It is particularly suitable for implementing long-term, stable functions like health checks.

Ultimately, I chose the third method:Adding a responsive pseudo-page path in the form of a plugin and implementing the complete logic of /generate_204 within the plugin. The reason is simple: this method neither relies on extra configuration at the Web Server layer nor clutters my theme code, while keeping the logic clear and functions independent, which perfectly fits the principles of my current blog architecture.

4 Detailed Implementation: REST API Route Registration (Plugin Method)

1 Overview

Since the goal is to provide a liveness probe interface that returns 204 No Content, we can fully utilize WordPress's built-in REST API system to meet this requirement. WordPress's REST API is a fully-featured and highly extensible mechanism that allows us to easily register custom routes without needing to introduce any extra plugins or modify core code.

In designing this interface, I tried to adhere to two principles: “cleanliness” and “stealthiness.” On one hand, it only responds to the simplest GET requests, accepts no parameters, and returns no body—its sole purpose is to be alive; on the other hand, it requires no authentication and uses a path that is not easily guessed (such as /wp-json/healthmonitor/check) to avoid falling into the detection patterns of generic scanners. This interface is essentially meant for machines; it should not expose too much information, let alone the backend structure.

Interestingly, the 204 status code is commonly used for “successful processing, but no content returned.” Compared to 200 OK, it reduces HTTP message redundancy slightly and allows various automated systems to complete the check process faster. From an “efficiency” perspective, it is a very appropriate choice.

2 Advantages of the Plugin Method

Implementing this custom liveness probe interface as a plugin, compared to directly modifying theme code or relying on Web Server rewrite rules, offers several prominent advantages:

• It has excellent structural independence. All logic is encapsulated within the plugin, which neither clutters the theme directory nor avoids the chaos of stuffing code into functions.php. This is particularly important for subsequent maintenance and collaborative development.
• This method is simpler and more direct to deploy. There is no need to adjust Nginx or Apache rewrite rules, nor is there a need to set up extra server path mappings. As long as the plugin is enabled, the interface naturally takes effect, maintaining consistent performance even when deployed across various hosting or panel environments.
• The portability of the plugin is also a major advantage. In the future, if the blog needs to change servers, domains, or even the entire architecture, as long as the plugin files are there, the liveness probe interface can continue to be used without extra configuration. This “portable” characteristic perfectly fits the portability needs of modern blogs.
• The plugin approach also demonstrates advantages in terms of security. You can explicitly declare via permission_callback that this route requires no authentication, keeping the interface always publicly accessible. This avoids the default restriction where the WordPress REST API is only open to logged-in users and prevents potential permission misjudgments. While keeping the interface open, it also maximizes control over the clear boundaries of access permissions.

3 Plugin Code Implementation

To implement a liveness probe interface dedicated to health checks, we can customize an extremely simple WordPress plugin.

First, create a subdirectory in the WordPress plugins directory, for example, named:

/wp-content/plugins/wp-healthcheck-rest/

Then create a main plugin file named wp-healthcheck-rest.php in that directory with the following content:

<?php
/**
 * Plugin Name: WP Healthcheck 204 (REST API)
 * Description: 提供一个用于健康检查的 REST API 接口，返回 HTTP 204，无正文。推荐用作 WordPress 探活/状态检查。
 * Version: 1.0
 * Author: tangwudi
 */

add_action('rest_api_init', function () {
    register_rest_route('healthmonitor', '/check', [
        'methods'  => 'GET',
        'callback' => function () {
            return new WP_REST_Response(null, 204);
        },
        'permission_callback' => '__return_true',
    ]);
});

This code accomplishes the following:

• Registers a REST route using the rest_api_init Hook;
• The route path is /wp-json/healthmonitor/check;
• Sets the request method to GET;
• The callback function directly returns an empty WP_REST_Response with a status code of 204;
• Sets permission_callback to __return_true, meaning the interface requires no permission verification and can be accessed by anyone.

After placing this plugin file in the wp-healthcheck-rest directory, simply log in to the WordPress admin dashboard and enable the plugin:

At this point, we have a stable, reliable, and standard-compliant liveness probe interface, suitable for calls by various load balancers, monitoring systems, or automation platforms.

5 Verification of Actual Results

Once deployed, you can directly use a browser to access the following address for verification:

http(s)://你的域名/wp-json/healthmonitor/check

However, accessing it via a browser results in the page flashing and disappearing, making it hard to take a screenshot. So let's try another method: you can use the simplest curl command for verification:

curl http(s)://你的域名/wp-json/healthmonitor/check

At this point, you will see that the terminalhas no output：

Although on the surface it seems like “nothing was returned,” this is precisely HTTP 204 No Content 's characteristic — the request was successful, but the serverexplicitly indicates there is no response bodyTo verify this, we can add the -i parameter to view the response header information:

curl -i http(s)://你的域名/wp-json/healthmonitor/check

The returned content is as follows:

Several key points can be seen from the output:

• The HTTP status code is 204, indicating that the request was processed successfully, but no content will be returned;
• The response body is indeed empty, you won't see any body in the terminal, and the cursor will just wrap to the next line and end;
• The response headers may contain fields such as Set-Cookie, Cache-Control, etc., reflecting the actual service running environment, but this will not affect the “emptiness” of the body.

Before using this REST route, my blog used a custom page /healthcheck as a liveness probe endpoint. Let's compare its performance in the same way. Using the simplest curl command, a large amount of HTML content is output directly in the terminal (the following is only a screenshot of the first page, there are more than ten pages after that, so I won't screenshot them all):

Although technically this can also be used for liveness detection, it has several obvious problems:

• It returns HTTP 200, which is not a semantic design specifically for liveness probing;
• The response body is a complete HTML page, which, even if very simple, is much more bloated than a 204 response;
• Theme templates, cache, SEO plugins, etc., may all affect the returned content, bringing unpredictable variables;
• Some reverse proxy tools or health check systems (such as Cloudflare's Health Checks) willmisjudge the page content as abnormal, thereby leading tofalse alarms, which is something I suffered from when I previously used/healthcheckthe page;
• Integrating it into systems like operations platforms and load balancers is also not “semantically clear” enough.

In contrast, the 204 response returned by /wp-json/healthmonitor/check is very clean, precise, and reliable, fully complying with the best practices in modern Web architecture for a “side-effect-free liveness probe endpoint”—it does not return any response body, and the status code clearly expresses “service online but no content needs to be returned”, which makes it bothavoid being cached by static caching mechanisms such as Cloudflare APO and WordPress cache plugins, and minimize the waste of bandwidth and response time, making it a purer and more stable form of health check.

6 Summary

The matter of a liveness probe endpoint may seem like an insignificant detail at first glance, but in reality, it is often a cornerstone of architectural evolution—especially when we start using Cloudflare Tunnel as an entry point, GitHub Actions for automated deployment, and third-party monitoring services to detect liveness, a “clear and high-quality liveness probe path” becomes indispensable.

Starting from the actual performance of common WordPress pages used for health checks, this article points out some of its unsuitability as a liveness probe endpoint, and then through custom ”register_rest_route()” registered a side-effect-free “/wp-json/healthmonitor/check” path, making it strictly return 204 No Content, with no body, no cache interference, and no ambiguity, fully complying with the general standards for liveness probe endpoints in modern Web services.

More importantly, this design approach is highly suitable for integration into an overall architecture of automation, edge computing, and cache collaboration. For example, Cloudflare APO does not cache responses with a returned status code of 204, and local cache plugins (such as WP Super Cache) can also avoid mistakenly caching such liveness probe pages; at the same time, tools like curl can be easily integrated and used, making the probing steps in CI/CD no longer dependent on tedious HTML or JSON parsing; and if it needs to be connected to load balancers or container orchestration platforms (such as Kubernetes' readinessProbe) in the future, it can also be smoothly connected without additional adaptation.

Of course, this approach to liveness probe endpoints mainly serves dynamic websites. If your site is already completely static, or even deployed on platforms like Cloudflare Pages, there is no need to design additional liveness probe logic—the CDN's own availability monitoring is already sufficient to handle fault detection needs.