starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Uptime will cache CDN,and cannot automatically update cache content #2406

New issue

Closed

opened 2026-02-28 02:53:39 -05:00 by deekerman · 10 comments

deekerman commented

2026-02-28 02:53:39 -05:00

Owner

Originally created by @qiaokuan1992 on GitHub (Jul 23, 2023).

⚠️ Please verify that this bug has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

Description

Uptime will cache CDN, After I update the content and refresh the CDN cache, uptime cannot automatically disable old cache content

👟 Reproduction steps

I set an wrong CDN information
Uptime performs domain name ping monitoring and obtains cached information from CDN
I updated the CDN information to the correct content
Uptime still uses incorrect CDN cache information for monitoring and continuously generates abnormal information alarms

👀 Expected behavior

Every time the runtime checks, it is important to avoid using the contents of the cache as much as possible; Alternatively, there may be a method for manually clearing the cache

😓 Actual Behavior

During runtime checks, the contents of the cache are constantly used and no way to forcibly refresh the cache has been found

🐻 Uptime-Kuma Version

1.21.2

💻 Operating System and Arch

Docker

🌐 Browser

Microsoft EDGE

🐋 Docker Version

20.10.17

🟩 NodeJS Version

📝 Relevant log output

No response

Originally created by @qiaokuan1992 on GitHub (Jul 23, 2023). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description Uptime will cache CDN, After I update the content and refresh the CDN cache, uptime cannot automatically disable old cache content ### 👟 Reproduction steps 1. I set an wrong CDN information 2. Uptime performs domain name ping monitoring and obtains cached information from CDN 3. I updated the CDN information to the correct content 4. Uptime still uses incorrect CDN cache information for monitoring and continuously generates abnormal information alarms ### 👀 Expected behavior Every time the runtime checks, it is important to avoid using the contents of the cache as much as possible; Alternatively, there may be a method for manually clearing the cache ### 😓 Actual Behavior During runtime checks, the contents of the cache are constantly used and no way to forcibly refresh the cache has been found ### 🐻 Uptime-Kuma Version 1.21.2 ### 💻 Operating System and Arch Docker ### 🌐 Browser Microsoft EDGE ### 🐋 Docker Version 20.10.17 ### 🟩 NodeJS Version - ### 📝 Relevant log output _No response_

deekerman

2026-02-28 02:53:39 -05:00

closed this issue
added the
bug

cannot-reproduce
labels

deekerman commented

2026-02-28 02:53:44 -05:00

Author

Owner

@louislam commented on GitHub (Jul 23, 2023):

There is no cache mechanism for caching content in Uptime Kuma.

Which monitor type did you actually mean? Ping or HTTPS?

And what exactly is "CDN information"?

@louislam commented on GitHub (Jul 23, 2023): There is no cache mechanism for caching content in Uptime Kuma. Which monitor type did you actually mean? Ping or HTTPS? And what exactly is "CDN information"?

deekerman commented

2026-02-28 02:53:45 -05:00

Author

Owner

@qiaokuan1992 commented on GitHub (Jul 23, 2023):

I use HTTPS to monitor the running status of the website. When my CDN configuration is incorrect, uptime show a message:
[MONITOR] WARN: Monitor #34 'Web': Failing: Maximum number of redirects exceeded | Interval: 20 seconds | Type: http | Down Count: 0 | Resend Interval: 0.

After I fix the CDN configuration, uptime will continue to loop and throw this exception message. However, accessing the website I monitor using a browser is normal

@qiaokuan1992 commented on GitHub (Jul 23, 2023): I use HTTPS to monitor the running status of the website. When my CDN configuration is incorrect, uptime show a message: [MONITOR] WARN: Monitor #34 'Web': Failing: Maximum number of redirects exceeded | Interval: 20 seconds | Type: http | Down Count: 0 | Resend Interval: 0. After I fix the CDN configuration, uptime will continue to loop and throw this exception message. However, accessing the website I monitor using a browser is normal

deekerman commented

2026-02-28 02:53:45 -05:00

Author

Owner

@louislam commented on GitHub (Jul 23, 2023):

Have written a special script that will flip 200/301 status code every 5mins, with cache headers.
Cannot reproduce it.

Since there is no cache mechanism, I believe it is not related to Uptime Kuma. Make sure you have cleared all caches in your CDN edge nodes.

https://louislam.net/test-301.php

<?php
// Cache for 1-hour
header("Cache-Control: max-age=3600");
header("Expires: " . gmdate("D, d M Y H:i:s", time() + 3600) . " GMT");

// Switch true and false every 5mins
$switch = (time() % 600) < 300;
if ($switch) {
    header("Location: https://louislam.net/test-301.php", true, 301);
} else {
    echo "OK";
}

@louislam commented on GitHub (Jul 23, 2023): Have written a special script that will flip 200/301 status code every 5mins, with cache headers. Cannot reproduce it. Since there is no cache mechanism, I believe it is not related to Uptime Kuma. Make sure you have cleared all caches in your CDN edge nodes. https://louislam.net/test-301.php ![image](https://github.com/louislam/uptime-kuma/assets/1336778/ff54b10b-70b7-4f86-bcfc-7b0469743ee0) ```php <?php // Cache for 1-hour header("Cache-Control: max-age=3600"); header("Expires: " . gmdate("D, d M Y H:i:s", time() + 3600) . " GMT"); // Switch true and false every 5mins $switch = (time() % 600) < 300; if ($switch) { header("Location: https://louislam.net/test-301.php", true, 301); } else { echo "OK"; } ```

deekerman commented

2026-02-28 02:53:45 -05:00

Author

Owner

@qiaokuan1992 commented on GitHub (Jul 23, 2023):

This 301 redirect exception was caused by an initial configuration error with the CDN, which has been fixed through reconfiguration and cleared the cache of all edge nodes. Currently, all browser accesses are normal.

At the same time, I just started a new uptime container, which is the same version as the current online version. In the new container, I used HTTPS to monitor this website, and the status is normal. Only when I visited the uptime container with redirection errors, I will still be prompted for too many redirects.

@qiaokuan1992 commented on GitHub (Jul 23, 2023): This 301 redirect exception was caused by an initial configuration error with the CDN, which has been fixed through reconfiguration and cleared the cache of all edge nodes. Currently, all browser accesses are normal. At the same time, I just started a new uptime container, which is the same version as the current online version. In the new container, I used HTTPS to monitor this website, and the status is normal. Only when I visited the uptime container with redirection errors, I will still be prompted for too many redirects.

deekerman commented

2026-02-28 02:53:45 -05:00

Author

Owner

@qiaokuan1992 commented on GitHub (Jul 23, 2023):

In my anomaly, the likely cause of the anomaly is https://www.domain.com Created CDN (with cache header) and configuration error caused the following 301 redirect exception:

1 http://www.domain.com Redirect to via 301 https://www.domain.com ;

2 https://www.domain.com Redirect to via 301 http://www.domain.com ;

And the CDN may also cache this redirect request, which is accompanied by a redirect request header. When our online production environment's uptime monitoring accesses this redirect, it begins to continuously generate

@qiaokuan1992 commented on GitHub (Jul 23, 2023): In my anomaly, the likely cause of the anomaly is https://www.domain.com Created CDN (with cache header) and configuration error caused the following 301 redirect exception: 1 http://www.domain.com Redirect to via 301 https://www.domain.com ; 2 https://www.domain.com Redirect to via 301 http://www.domain.com ; And the CDN may also cache this redirect request, which is accompanied by a redirect request header. When our online production environment's uptime monitoring accesses this redirect, it begins to continuously generate

deekerman commented

2026-02-28 02:53:45 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jul 24, 2023):

Currently, I could not replicate this issue.
Can you provide us a Minimal, Reproducible Example?
Louis set caching headers on his MRE.

@CommanderStorm commented on GitHub (Jul 24, 2023): Currently, I could not replicate this issue. Can you provide us a [Minimal, Reproducible Example](https://stackoverflow.com/help/minimal-reproducible-example)? Louis set caching headers on his MRE.

deekerman commented

2026-02-28 02:53:45 -05:00

Author

Owner

@qiaokuan1992 commented on GitHub (Jul 24, 2023):

I attempted to configure 301 redirection between HTTP and HTTPS in nginx and added cache headers:

  add_header 'Cache-Control' 'public';
  add_header 'Expires' '3600';
  add_header 'Etag' '64880c2b-5bf';
  add_header 'Last-Modified' 'Tue, 13 Jun 2023 06:26:51 GMT';

But I was unable to reproduce this issue, and I added my domain name again in the uptime of the production environment. At the beginning, the monitoring was normal, but after running it a few times, there was another abnormal message with too many redirects

@qiaokuan1992 commented on GitHub (Jul 24, 2023): I attempted to configure 301 redirection between HTTP and HTTPS in nginx and added cache headers: ``` add_header 'Cache-Control' 'public'; add_header 'Expires' '3600'; add_header 'Etag' '64880c2b-5bf'; add_header 'Last-Modified' 'Tue, 13 Jun 2023 06:26:51 GMT'; ``` But I was unable to reproduce this issue, and I added my domain name again in the uptime of the production environment. At the beginning, the monitoring was normal, but after running it a few times, there was another abnormal message with too many redirects

deekerman commented

2026-02-28 02:53:45 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jul 24, 2023):

Please provide all the details about the test setup with which you can reproduce this behaviour.
What is your nginx configuration, what did you do between test runs?
Providing a Minimal, Reproducible Example in this case is very nessesary to be able to reproduce this.

@CommanderStorm commented on GitHub (Jul 24, 2023): Please provide all the details about the test setup with which you can reproduce this behaviour. What is your nginx configuration, what did you do between test runs? Providing a [Minimal, Reproducible Example](https://stackoverflow.com/help/minimal-reproducible-example) in this case is very nessesary to be able to reproduce this.

deekerman commented

2026-02-28 02:53:45 -05:00

Author

Owner

@qiaokuan1992 commented on GitHub (Jul 24, 2023):

in my case, I use CDN services cache my domain static files,
first, enable domain https setting in CDN services, set upstream to domain http server in port 80, this CDN cache expire time is 30d.
Then set nginx config for http server (port 80), use 301 redirect to https server (port 443), at this time, use browser or uptime request https://mydomain.com, has message with too many redirects.
When I changed the upstream server port of CDN to 443, When I changed the upstream server port of CDN to 443, However, there is still this error message in uptime.

I am very sorry that I cannot conduct further experiments to reproduce this situation as I do not have private CDN resources.

@qiaokuan1992 commented on GitHub (Jul 24, 2023): in my case, I use CDN services cache my domain static files, first, enable domain https setting in CDN services, set upstream to domain http server in port 80, this CDN cache expire time is 30d. Then set nginx config for http server (port 80), use 301 redirect to https server (port 443), at this time, use browser or uptime request https://mydomain.com, has message with too many redirects. When I changed the upstream server port of CDN to 443, When I changed the upstream server port of CDN to 443, However, there is still this error message in uptime. I am very sorry that I cannot conduct further experiments to reproduce this situation as I do not have private CDN resources.

deekerman commented

2026-02-28 02:53:45 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 14, 2023):

Closing as this is highly likely a duplicate of or resolved by #575

@CommanderStorm commented on GitHub (Dec 14, 2023): Closing as this is highly likely a duplicate of or resolved by #575