Contents
1 Introduction
This is not the article I originally planned to write this week. However, when I was researching the impact of APO on WordPress content caching, I accidentally discovered an abnormal situation: the response header of the blog access request appeared.Cf-Cache-Status: BYPASS":

The most important thing is that no matter how I refresh, it always says "BYPASS", which means that APO's access request to my blog is invalid (I don't know the actual impact of the problem, but I know that at least it is the case for my access request). This makes me very upset. After all, I am now a noble Cloudflare Pro user, and the APO function is an expensive service sold separately for $5 a month, so how can it not work? This matter must be taken seriously!
To figure out what was going on, I had to change direction midway, delve deeper into the phenomenon, and try to identify the triggers of the problem.
2 General content parsing of WordPress site response header after enabling APO
Under normal circumstances, when using APO, the response header should look like this:
Cache-Control: max-age=14400, must-revalidate Cf-Apo-Via: tcache Cf-Cache-Status: HIT Cf-Edge-Cache: cache,platform=wordpress
But what I encountered wasCf-Cache-Status:BYPASS
, the cache is bypassed, and the reason is because of an unconventional cookie, so we need to test to find out which cookie causes this situation.
Under normal circumstances, after APO is enabled, when a visitor's browser accesses a WordPress site, the response header received should contain the following key fields:Cache-Control,cf-apo-via,cf-cache-status,cf-edge-cacheThe specific meanings of these fields are as follows:
1. Cache-Control: Defines the cache policy, specifies the storage duration of the content and whether revalidation is required. Common values include:
• max-age=xxxxx: indicates that the cache validity period is xxxxx seconds.
• must-revalidate: requires revalidation of the content after expiration, usually used with max-age.
• no-cache: indicates that caches can store the response, butYou must re-authenticate with the source server before each use(That is, do an ETag or Last-Modified header check.) This ensures that the cached content is always fresh, but still reduces the number of full downloads.
• no-store: indicatesStorage of response data is strictly prohibited, neither the browser cache, CDN nor the proxy server can save the content, and each request will re-retrieve the complete resource. This value is usually used for sensitive data (such as login pages, bank transactions, etc.).
2. Cf-Apo-Via: Indicates the data source of Cloudflare APO. Common values include:
• tcache: Indicates that APO serves content from the Cloudflare edge cache, which is a normal cache hit status.
• origin,cookie: indicates that the browser request carriesNon-conventional Cookies Instead, the APO cache is bypassed and content is retrieved directly from the source. This usually happens when a user logs in, a specific plug-in sets a cookie, or some custom rules are triggered.
• origin,no-cache: Indicates that the request bypassed the APO cache due to the presence of the Cache-Control: no-cache header and went directly back to the origin to get the content. This means that Cloudflare is allowed to cache the page, but must re-verify the latest state of the origin server (for example, check ETag or Last-Modified) before serving the cached content. If the origin server response has not changed, Cloudflare may still return the cached content, but it will add an additional request back to the origin.
3. Cf-Cache-Status: Indicates the Cloudflare cache status, possible values include:
• HIT: Cache hit, the content comes from the cache of Cloudflare edge node.
• MISS: Cache miss, need to go back to the source to obtain.
• BYPASS: Cloudflare goes directly back to the origin due to certain rules (such as cookies or specific response headers).
• EXPIRED: The cache has expired and needs to be re-acquired and updated.
4. Cf-Edge-Cache: Indicates APO's cache policy on WordPress sites, usually "cache,platform=wordpress", indicating that Cloudflare has optimized caching for WordPress sites.
3 Problem reproduction
3.1 Simulate opening the home page for the first time
After I cleared all browsing history and cookies in Chrome, I opened the blog homepage for the first time:

At this time, the access is normal, the status of "CF-Cache-Status" is "HIT", and the cookie (first party) generated by my blog at this time is as follows (there are 6 cookies, mainly the bottom 3):

This is the cookie status when APO cache is working normally. Mark it first.
Now that we have confirmed that there is no problem with the first visit to the homepage, we will proceed to the next test: reload (because in my case, no matter how many times I reloaded, it was BYPASS, so I couldn't help but suspect that it was related to reloading).
3.2 Reload test
3.2.1 Introduction to reload types
Chrome browser provides three different loading methods, each with different cache processing logic:

- Normal Reload
• Trigger method: Press F5 or click the Refresh button
• Cache Behavior:The browser will send a request to the server to check whether the cache is still valid (through response headers such as ETag and Last-Modified); if the server returns 304 Not Modified, the cached data will continue to be used; only some resources (such as HTML files) may be re-pulled, and other resources (such as CSS, JS, pictures, etc.) may still be loaded from the cache.
- Hard Reload
• Trigger method: Press Ctrl + Shift + R (Windows/Linux) or Cmd + Shift + R (Mac)
• Cache Behavior: Force re-download of all resources (HTML, CSS, JS, images, etc.) from the server, but Service Workers may still intercept requests, serving data from cache.
- Empty Cache and Hard Reload
• Trigger method:Open Developer Tools (F12 / Ctrl + Shift + I) → Right click the refresh button → Select "Clear cache and hard reload"
• Cache Behavior: Clear all caches (including HTTP cache and stored Service Worker cache) and force re-download of all resources from the server.
To summarize:
Loading method | Whether to use cache | Check whether the resource is updated | Whether to clear the cache |
---|---|---|---|
Normal reload | Possibly using cache | Yes (via ETag, Last-Modified) | no |
Hard Reload | No cache | No, get it directly from the server | no |
Clear cache and hard reload | No cache | No, get it directly from the server | yes |
Practical application scenarios
• Normal reload: Generally used to reduce unnecessary resource downloads and increase page loading speed.
• Hard Reload: Applicable to situations where you find that the page is not updated in a timely manner, or some resources (such as CSS, JS) do not seem to be updated correctly.
• Clear cache and hard reload: Suitable for troubleshooting cache issues, debugging web applications, or ensuring that the latest resources are loaded (such as front-end development or testing after a new deployment).
The second "hard reload" and the third "clear cache and hard reload" are generally similar, so this time we will only use the first and second reload methods.
Note: If the browser actively requests to bypass the cache (for example, hard refresh Ctrl + F5 or disable the cache in the developer tools), it usually carries "Cache-Control: no-cache" and "pragma: no-cache" in the request header to indicate that the server is required to revalidate or directly obtain the latest content. In this case, Cloudflare will also follow the browser's request and directly return to the source to obtain data without using the APO cache. In Cloudflare's response header, this return-to-origin behavior may be reflected in cf-apo-via: origin,no-cache, indicating that the request bypasses the APO cache due to the presence of the no-cache header.
3.2.2 Normal reload and hard reload tests
1. Normal reload
First use the "normal reload" method to verify. I tried many normal reloads of the homepage, and multiple normal reloads after selecting a certain article, and there were no problems.
2. Hard Reload
Then perform the "hard reload" verification, and this time "Cf-Cache-Status: BYPASS" appears for the first time:

However, it is normal for "Cf-Cache-Status: BYPASS" to appear at this time, because as mentioned above,Hard Reload Essentially, the browser actively requests to skip the cache and get the latest content directly from the origin server. This can be seen from the "Cache-Control: no-store, no-cache, must-revalidate" and "Cf-Apo-Via: origin, no-cache" in the response header, indicating that Cloudflare complies with the browser's request and does not use the APO cache.
However, the following is not normal. No matter how many times "normal reload" is performed, "Cf-Cache-Status" is always "BYPASS", and "CF-Apo-Via" becomes "origin,cookie":

That is to say, as long as a "hard reload" is performed, a certain (or some) unconventional cookies will appear. This (or these) unconventional cookies will always exist and will cause the APO cache of any subsequent visits to my blog to become invalid. The direct manifestation is that "Cf-Cache-Status" is "BYPASS".
3.2.3 Analysis of the Causes of the Problem
From the analysis in the previous section, we can see that several key parameters of the response header have changed, clearly indicating that Cloudflare APO Cache miss, but directly return to the source to request the page content.
First, Cache-Control: no-store, no-cache, must-revalidate indicates that the origin server explicitly instructs the browser and Cloudflare Don't cache pagesEach request must be re-verified or even directly retrieved from the source. Secondly, the Cf-Apo-Via: origin, cookie further indicates that Cloudflare APO Bypassing cache due to detection of cache-impacting cookies, directly requesting the origin server. Finally, Cf-Cache-Status: BYPASS confirms this, and Cloudflare believes that the requestDoes not meet cache conditions, so no caching is provided.
In summary, the main reasons for APO cache bypass are:Specific Cookies, and these cookies may be due to Hard Reload There may be other unconfirmed triggering factors. Therefore, the key point to be investigated is What actions cause these cookies to be set?, and howPrevent unnecessary cookies from affecting the APO cache.
Now let's take a look at the situation of cookies. There are 4 more cookies, as shown in the blue box in the red box in the following figure:

Among these four extra cookies, "PHPSESSID" and "argon_user_token" are found on websites using WordPress and the argon theme, so they are directly excluded. Of the remaining two, I immediately locked onto the "wp-editormd-lang" cookie. After all, the name doesn't sound like a serious cookie. Is this cookie the cause of "Cf-Cache-Status: BYPASS"?
In order not to wrongly accuse good cookies, we actually verify it.https://blog.tangwudi.com
Delete the "wp-editormd-lang" cookie:


Then use the "normal reload" method to verify and find that the APO cache is normal:

Now it is completely certain that the cookie that causes the "Cf-Cache-Status: BYPASS" problem is "wp-editormd-lang".
4.1 Cause Analysis
When I saw this cookie name, it immediately looked familiar to me, and it was also related to the Markdown editor. The only Markdown plugin installed on my WordPress site is WP Editor.md, so it can be basically determined that it is setting the wp-editormd-lang cookie.
Why does “WP Editor.md” set this cookie?
From the name, wp-editormd-lang may be used to store Markdown editorLanguage Preference, which may include:
- Remember the user's language setting: For example, the plug-in may support different languages such as zh-CN (Chinese), en (English), etc., and use cookies to record the last selection so that it can be automatically applied the next time you visit.
- Ensure editor UI renders correctly: Some UI components may rely on this cookie to decide which language file to load.
- May involve AJAX interaction: If the plugin's Markdown preview or parsing function needs to be loaded via AJAX, it may carry this cookie to ensure that the server returns the correct language version.
Why does Cloudflare APO use BYPASS caching?
Cloudflare APO will detect cookies and if a request or response carries Non-WordPress Core Cookies, it might think that the page isUser-specific dynamic content, thereby bypassing the cache and directly returning to the source to obtain the page. This is to prevent After caching user A's page, user B sees incorrect content when accessing it.
Since wp-editormd-lang is not a WordPress core cookie, Cloudflare may assume by default that the page contains user-specific content and therefore not cache it, resulting in APO BYPASS(My guess, accuracy is not guaranteed).
4.2 Problem Solving
There are two most direct ways to solve this problem:
- 1. Don’t useWP Editor.mdThis plugin: But it works pretty well for me, I don’t want to change to other ones, it’s too troublesome, so I give up
- 2. LetWP Editor.mdPlugins should not set this cookie: It is definitely impossible to ask the author to change the plugin, but you can find a way to let WordPress itself meet this requirement.
At present, the second method seems to be the most feasible. After some research, you can directly add the following code in functions.php and save it:
add_action('init', function() { if (!is_admin()) { // Only execute on the front page setcookie('wp-editormd-lang', '', time() - 3600, '/'); } });
The purpose of this code is to clear the wp-editormd-lang cookie in the "front-end page only" scope, ensuring that the cookie Does not affect Cloudflare APO cache, thus avoiding the CF-Cache-Status: BYPASS problem. At the same time, since it is not executed in the WordPress background, editor-related functions can still be used normally and are not affected.Retains the caching advantages of APO,againDoes not interfere with background plugin functions, is an optimization solution that takes into account both performance and functionality, but its only disadvantage is that "setcookie()" can only be used in Before HTTP response headers are sent Execute, modify The browser carries the cookie in the next request, and the current request already carries "wp-editormd-lang", Cloudflare APO will still see this cookie, thus triggering BYPASS.
Then try in sequence: "Hard Reload", after which the "wp-editormd-lang" cookie appears, and then "Normal Reload", the "wp-editormd-lang" cookie disappears, success! Friends who are interested in this result can visit my blog on their browser to verify it.
In fact, I don’t recommend directly modifying any WordPress theme files now, because I often forget about the changes after a while. Over time, the theme files are changed into a mess, and I don’t even know what I changed, not to mention how much trouble it will be to keep the current functions when I change the theme.
So if there is a function that requires modifying the WordPress theme file to implement some functions, such as the function in this article, which method is the best? In fact, it can be achieved through WordPressCode SnippetsThis plugin, the free version, can run PHP and HTML codes, and can manage all the functions that originally needed to be added to the theme file through the plugin, which is very convenient for management:

Note: Then I had another question: the Expires time of the cookie "wp-editormd-lang" is "session", but why does it still exist? I don't know how many times I restarted the system, and I closed the browser completely countless times, but this "session" is still there? This is not scientific. Unless a function of the Chrome browser: "Keep session on exit" or "Restore last session" is effective in this scenario, then even if the browser is closed, the Session Cookie may be restored. So I made an attempt, first turning off the PHP code in the "Code Snippets" plug-in, and then turning off this function of the Chrome browser: in "Settings"-"Start Page", change the original "Continue browsing the last opened webpage" to "Open a new tab":

Finally, after clearing all cookies and re-testing, the result is that the "wp-editormd-lang" cookie is gone when opening a new tab or reopening the browser after completely closing it. It turns out that the problem is not with the cookie itself, but the "session restore" function brings it back. This is considered a browser problem. "Pseudo" session persistence mechanismThis is actually useless, because most browsers now have this feature enabled.
5. Afterword
Finally put thisPainfulThe problem has been solved, otherwise the $5 APO subscription will be wasted! However, looking back, ordinary visitors to my blog generally don't "hard reload" the page for no reason, so it is likely thatThe only one who is really affected is me.After a long time, it turned out to be like a "A Solitary Carnival".
However, from another perspective, although this repair is onlyThe cache bypass issue that was triggered by accident, but after all, through layer-by-layer investigation, I found the root cause of "WP Editor.md plugin cookies affecting Cloudflare APO cache". This not only solved the current APO cache BYPASS problem, but more importantly, it made me realize that if some future plugin functions or AJAX requests also carry similar cookies, it may also cause Cloudflare to misjudge the page as dynamic content, thereby bypassing APO's cache, and then affectingAccess speed for more users.
Therefore, this investigation not only optimized the siteStability and loading speed, and let meAnalyze and resolve APO cache exceptionsOn the other hand, I have accumulated practical experience. Cache-Control And the understanding of related response header parameters is also more thorough: from the previous half-understanding to the real mastery, so this experience can be regarded as an unexpected but fruitful practical learning course.
另:不得不又感叹一下,Writing it down is so importantBefore I planned to organize the troubleshooting process into an article, my thoughts were scattered, and my analysis of the problem was superficial. Many details were just vague and I could not get to the point. Once I started writing it down, I had to analyze the whole problem.Systematic combing, not only makes the thoughts clearer, but also discovers the details that were previously overlooked, and even finds breakthrough points unexpectedly in the writing process. More importantly, this kind of writing is not only a record, but also aDeep thinking and knowledge accumulationToday, it seems that a specific problem has been solved, but this process itself has also formed a reusable troubleshooting idea. When encountering similar situations in the future, you can find the direction more quickly and even help others avoid detours.
Therefore, writing it down is not only a review, but also a way to make progress.
博主的Wordpress是建在家里的服务器上了嘛
对,群站所有的应用都部署在家里,只有图床部署在R2 上,方便多个站点切换。