First load extremely slow then fast as usual

This post was flagged by the community and is temporarily hidden.

1 Like

TTFB is usually delayed due to Cloudflare waiting for your server to respond. If you post the hostname, we can take a closer look.

Thanks @sdayman
once it does the first load the TTFB is around 100ms

1 Like

As was mentioned, this is probably a issue at the origin. You said you were DDoSed… are they still hitting origin via IP address or cached DNS entries or did you firewall the origin off and open it up only to Cloudflare? Is there some sort of rate limiting system in place at the origin; moving to a CDN concentrates where requests are coming from (only Cloudflare, in this case) which could trigger a simple rate limiting system.

1 Like

I’m no longer under DDos, my server load is very load.
i’m not aware of any rate limiting, i’m trying to check this better. Wouldn’t the rate limit apply to all the loads and not only on the first one? also the wordpress installation always load fine.
Thanks for the suggestions robert, much appreciated!

It’s definitely the server. It looks like you’re using a Digital Ocean droplet, configured by Runcloud. Runcloud may have configured short-term NGINX cache.

Digital Ocean will let you create a firewall where you can block HTTP/S traffic from anyone not coming through Cloudflare IP addresses.

@sdayman, just curious, how did you get the origin IP address?

A DNS history site.

Thanks again for your reply, please have a bit more patience with me.
I found the firewall settings and will try to set all the IPs, this is a suggestion to fix the problem or to additional improve the security in case of DDos? ( not tried yet to because I’m not yet sure if this may interfere with proxies being use on the platform)

The short-term NGINX could be a problem with cloudflare? it always worked fine with the current setup from runcloud

This is the configuration

Do not edit this file

Editing this file manually might break RunCloud System

If you think there is a bug, contact us at

server_tokens off;
error_log /home/runcloud/logs/nginx/runcloud-blog_error.log;
access_log /home/runcloud/logs/nginx/runcloud-blog_access.log main buffer=16k;
access_log /var/log/nginx-rc/runcloud-blog_traffic.log traffic buffer=16k;

client_max_body_size 256m;

include /etc/nginx-rc/conf.d/runcloud-blog.d/headers.conf;

root /home/runcloud/webapps/runcloud-blog;
index index.php index.html index.htm;

location ~ /.well-known/acme-challenge {
allow all;
log_not_found off;
root /opt/RunCloud/letsencrypt;

location / {
include /etc/nginx-rc/extra.d/runcloud-blog.location.root.*.conf;
include /etc/nginx-rc/proxy.conf;

location ~ /. {
deny all;
access_log off;
log_not_found off;

location = /favicon.ico {
log_not_found off;

location = /robots.txt {
allow all;
log_not_found off;

location ~ .(ico|css|gif|jpe?g|png|gz|zip|flv|rar|wmv|avi|css|js|swf|png|htc|mpeg|mpg|txt|otf|ttf|eot|woff|svg|html)$ {
expires 1M;
include /etc/nginx-rc/conf.d/runcloud-blog.d/headers.conf;
add_header Cache-Control “public”;
include /etc/nginx-rc/extra.d/runcloud-blog.location.static.*.conf;
try_files $uri @proxy;

location ~ .(html)$ {
expires 24h;
include /etc/nginx-rc/conf.d/runcloud-blog.d/headers.conf;
add_header Cache-Control “public”;
include /etc/nginx-rc/extra.d/runcloud-blog.location.html.*.conf;
try_files $uri @proxy;

include /etc/nginx-rc/extra.d/runcloud-blog.location.main.*.conf;

location @proxy {
include /etc/nginx-rc/proxy.conf;

server health stats

Firewall settings are to stop attackers from bypassing Cloudflare and hitting your server directly. This only works if there are no direct services on the server that can’t go through Cloudflare.

RunCloud keeps their cache configs in /etc/nginx-rc/extra.d/

Now that I look at it, it would have shown an additional cache header: x-runcloud-cache

You’re going to have dig into what’s happening on the server.

I “fixed” it

I did a fresh installation on the same server to check if it was the server, and the new installation had the same problem!
So i moved it to a new server, thanks to cloudflare has been quite fast, and now it’s back as it used to be!

I don’t really undestand what happened to that poor server to behave like that

Something with the DDos for sure

31 hours to completely fix from the start of the ddos

Well, at least, i feel more experienced now, and I had been posponing the server transfer out of DO for months to avoid trouble.

I really appreciated your help guys, thanks for your time!


Excuse me, are you the person in charge of storyvoter?
I have mail for you, I ca n’t enter the website, I want to know what ’s happening.