Cloudflare TV
On Air
Schedule
Shows
No results were found
Powered by Stream
Top 10 Customer FAQs
Presented by Jamie Ede
Share
Copy Link
Email
Facebook
LinkedIn
Twitter
Start at
Originally aired on
January 6, 2022 @ 4:30 AM - 5:30 AM EDT
Discover our customers' top questions and the answers to them.
Original Airdate: July 13, 2020
English
Q&A
Transcript
(Beta)
Hello and welcome to this Cloudflare TV segment for CSUP TV where I will be going over the top 10 FAQs for customer support here at Cloudflare.
So please ask as many questions throughout this and I will try to answer them.
So email livestudio at Cloudflare.tv.
There's also a direct link to email if you're watching the show on Cloudflare.tv so it's easy to get in contact and it's great to hear from you guys.
So with this I'm going to try and go over the top 10 I'd say of the requests we get from customers where there are ways you can help yourself and like ways to avoid them and solve them yourself and the ways you can troubleshoot the issues and what they mean etc.
So my name is Jamie Ede. I am the technical trainer for the technical support team at Cloudflare.
I am based in San Francisco so I work in that office.
There's also technical trainers in the other regions as well. So I was a technical support engineer for two plus years before changing to this role as a technical trainer.
So I've seen the tickets, I've worked the tickets and I've helped customers with a plethora of interesting issues, easy issues, hard issues, impossible issues.
So it's a great role to have and seeing Cloudflare like that is just so much fun.
So what I'm going to go over, these are the things I'm going to cover in this session.
So the top 10 are going to be DNS incorrect name servers. So what that means is you've tried to add your domain to Cloudflare, you think you've done it correctly, you know, changing the name servers to like Elliot.ns.Cloudflare.com and it's not working.
So I'll just explain a bit about that and what ways you can, you know, alleviate those issues.
The second one I'm going to cover is RAID. What is it?
Why do we need it? So I'll cover that briefly as well. Another one of our top ones is why isn't my page rule working?
So page rules are great. And I'll go over a couple of ways you can work out why a page rule isn't working and how you can avoid things when you're setting page rules up for yourself.
I'll also cover DNS, like the difference between an orange clouded DNS record and a gray clouded DNS record.
And also mixed content issues I will go over. So mixed content issues is like a SSL TLS thing where resources on the web page aren't loaded securely.
So you have like an insecure message and I'll show you what they mean.
Minimum TLS version, which one?
So that kind of means, you know, we've got the setting in the Cloudflare dashboard where you can choose which minimum TLS version you wish to have on your website.
I'll go over the pros and cons of those and things like that. Next thing would be, is a site using Cloudflare?
So easy ways to find out if a site is, you know, active on Cloudflare and running over our network or not.
Next one, 5xx errors.
Is it Cloudflare? So one of the main things we get is people writing in with issues on their websites with like 502, 503s, 522s, etc.
Those kind of errors.
And like, is it a Cloudflare issue? Or is it something you can fix yourself?
Is it a setting, misconfiguration, etc. Next thing would be how can I block an IP address?
You know, like a bad party, or you just want to lock down an area of your website.
I'll go over some of the things you can do with that. And yeah, so the last one, error, too many redirects.
So this is one of the common things we get when someone newly onboards to Cloudflare, they're trying to set it up in the best possible way, but they switch a couple of switches they and cause this error to appear in the browser when you're browsing to the website.
So let's start. So DNS, incorrect name servers.
So with a lot of these slides and things, I will be doing interactive segments where I will show you exactly things using terminal, using the Cloudflare dashboard, and some websites where these issues are present.
But this one, I haven't got anything, I'm just going to try and explain it.
So the usual way to activate a zone on Cloudflare is the full setup, which means you delegate your authoritative name servers to us, which is at your registrar.
So the issue we have is one of the main ways people get this wrong would be setting the name servers, not at the registrar.
So the registrar is where you've bought the domain from.
So you know, when you're looking, you're setting up your company, and you think of the great idea of the name of your company, and then you go to a website and you purchase the domain name, and you pay it per month, etc.
No, per year, sorry.
And that's where, that's the registrar. So the registrar would be where you bought the domain from, and that would be where you need to set the name servers that we've given you to activate the domain on Cloudflare.
So people, there's also another way people get this wrong.
It's setting the correct way, it's setting the correct area, like you've done it at the registrar, but you have misspelt it.
So you've misspelt Cloudflare, you've misspelt the name, like Elliot maybe, you spell that incorrectly.
So the best way to mitigate that is to use the copy and paste function during the onboarding of a domain on our dashboard.
So then there's no misclicking, you just click copy, and then open up your registrar in a new tab, go to your name service area, and change the images, paste it in, paste both of them in exactly as they're shown, and then update.
And that should alleviate these two main issues.
So you should always make sure you're setting them at the registrar level, and make sure you're spelling them correctly.
So just double check, that's one of the things I'd say here.
And again, I'm going to reiterate, please ask questions about support, about any questions you have, and I'll try, if I have time at the end or during, to answer them for you.
Next one, RayID.
So we're going to get a little bit of interactivity here. Why do we need it?
So first of all, I'm going to say, what is it? It is a unique identifier for requests that go over Cloudflare.
So seeing as I was a technical support engineer before, you use these daily, like 10, 20, 30, up to 100 times a day, you're analyzing RayIDs, or using them as part of your workflow to diagnose an issue.
So they are super helpful, because the RayID string can be decoded to show the data center location and timestamp of a request.
So this is all covered on our support knowledge base at support .Cloudflare.com.
So this is all public information, and you can find out exactly what they are, but it just really helps support if you send these in when you need our help, right?
So if you send us the RayID and explain what the issue is, we'll know kind of where to go to find the answer to your question, slash find out the underlying cause of your issue.
So you can see the RayID when you send a request to a website that is on Cloudflare, and is over an orange clouded DNS record.
So you can also view them in Chrome using dev tools, etc.
So right now I'm gonna just show you a quick thing. If you run a curl request, it's just a normal request to a website that is on Cloudflare, you will see this.
So I'm going to go to csuptv.com. If I just go there, see it shows us this is the reply back in the headers, see the back arrow there, so you see these are all the replies we got back from the Cloudflare edge, our network to my terminal here.
So we can see here the RayID is here, named cfray, and they look like this.
So it shows sjc, that's the data center that this request hit, which is San Jose, and this part here is what support can use to help diagnose the issue you're having.
So sending those in would be very helpful, and as you can see they're appearing in this request.
If I send another request, so we see this one I did just then ends in 34c.
If I send another request, it's different.
See we're getting d87, so like that's not the only part different, but I'm just showing you that each RayID is unique to that exact request.
So it helps if you get the exact RayID of when the issue occurs and not a RayID thereafter.
It's a lot better to have a RayID that is for when the issue occurred.
In some instances just sending a RayID can be helpful in any regard, but most of the time we need one of when the issue occurred, so try and get that when you're writing into us or trying to look into issues yourself because they're very, very helpful.
And remember, please ask questions if you have any and I will answer them.
Let's go back to the slides for one second.
So yeah, you can also view them in Chrome DevTools, so I'm going to show you that as well because it's helpful to know.
So if you open up any website that's on Cloudflare, you will see it like this, it's on Cloudflare.
If we then go to the right click, inspect, or go up here to the menu here, go to more tools and then developer tools, it will open the same thing or the keyboard shortcut if you want.
So if we go to the network tab inside Chrome and just refresh, I'm just going to do a basic refresh.
There we go, it's loaded and we can see the first request is here.
If I click on it, it opens up this area here. Let me make this slightly bigger.
I don't know how big this is, so I'm just going to zoom in slightly. So for you guys, you clicked on this request, which was for the main request for the blog.
We can see what we sent out and the remote address we're hitting. If we scroll down here to the response header section, we can see there's the RAID.
So the RAID shows everywhere, it's on every request, so you'll be able to view it however you're using a Cloudflare site and be able to extract it to send it to support, either via just copy and pasting here or even better, right clicking and then going to save all as ha with content.
But I'll go over that a bit more later on when I'm going over the best way to contact support and the information we need.
And remember, any questions, please write in. So back to my slides.
As we can see here, it shows a number of requests that's orange clouded DNS record.
So that means, because you know in the Cloudflare dashboard, you can orange or gray cloud DNS records, right?
So an orange clouded means it's going over the Cloudflare network.
A gray clouded means it is not. It means it's going directly to your origin, exposing your origin IP address to the world, etc.
So that's why our features will not run, there will be no RAIDs, etc. So for your security, and if you want to utilize Cloudflare in the best possible way, orange clouding is the way to go.
For web appliances that are compatible. So that'd be any web kind of thing, but nothing that is like email servers, etc.
You can't orange cloud those.
There's certain records which you should keep gray clouded, but the vast majority of web appliances, orange clouding is the best way to go, especially if you want to use our protection for DDoS, our WAF, etc.
Next up, why isn't my page rule working?
Okay, so page rules are powerful. They allow you to change Cloudflare settings on different parts of your website.
For example, redirecting all traffic from one subdomain to another, or setting cache, SSL, and performance settings granularly to a set part of your website based on URL with wildcards, and so much more.
There's just so much you can do with them. So one thing to note there is only one page rule would execute per request.
So you can't have like five page rules running on one page.
It won't work. That's not how it works.
So there are a few reasons why it isn't working. The records you're trying to run the page rule on is gray clouded, and like I said previously, any Cloudflare setting will not work unless the record itself is orange clouded and going over the Cloudflare network, right?
So that's that one. Number two, the URL pattern is incorrect.
So what that means is the URL matching pattern which you can do inside page rules, it doesn't match what you're trying to do.
So you just need to, there is documentation at support.Cloudflare.com that goes over the exact ways to use it.
It is quite simple once you understand the concept.
So like forward slash star will catch everything after the forward slash, etc.
So there's a lot of things there to make sure that you have the matching pattern, like exactly how you want it in your scenario.
And then the next one is, it is working, but the setting change needs a cache purge to take effect.
So what that kind of means is, let's say you've changed your cache TTL, which is how long you want resources to be set inside cache on the Cloudflare network.
If you change that setting from let's say previously it was one hour and then you want to send it to 10 seconds, you set that page rule up and then you wait 15 seconds.
You try the request for the resource that should now only be cached for 15 seconds and you see that it's still in cache based on the old TTL time to live.
That the page rule needs to activate, you need to purge the cache for it to then run.
Or you can wait it out until the old TTL expires and then it will cache based on your page rule rule.
So that's the ways we see that. There's also the fourth one is there is a page rule conflict.
So a matching page rule above has ran and means like the one underneath it won't run.
So it will match first, whichever one it matches first in the list, it will run that one.
So if you've got like a wild card above, it will run before your more specific one underneath.
So that way you need to change the order and bring that one above, that kind of thing.
So I'm now just going to show you a bit of that inside the Cloudflare dashboard.
I just need to find the right tab, give me a second.
I'm just loading up the Cloudflare dashboard, please give me one moment.
Okay.
I'm going to leave you that page for one moment while I load up what I need to load.
So yeah, there'll be ways in which you need to make sure that you have the correct settings, etc.
When you're loading into the Cloudflare dashboard and like your page rules need to make total sense with what you're trying to do.
So I'm just going to load up the Cloudflare dashboard.
So what I'm loading up now is I'm just logging into the Cloudflare dashboard, so I can just show you exactly what I mean here.
So now I've done that, you should now be able to see the Cloudflare dashboard.
So if we go into csuptv.com and we go straight to page rules, we'll see here I have a page rule here called oldblog.csuptv.com forward slash star.
And what this one does is forwarding URL with a permanent redirect to blog.csuptv.com forward slash dollar sign one.
So what this means is anything I write after the forward slash here in the star will get translated here.
So let's try that now and it should work.
So I'm going to go to oldblog.csuptv.com forward slash cheese.
If I hit enter, oh we get 404 not found and nothing's happened here.
So this hasn't redirected. What could be the problem here?
Let's have a think. Okay let me just check the DNS of this.
There we go. We can see here old blog is gray clouded right. So what we need to do is go to edit, orange cloud it, and then press save.
So now this is orange clouded.
We will see old blog now shows as orange clouded here. This page rule should now run.
So if we now refresh this, we may need to give it a, it's redirected straight away as you can see to blog .csuptv.com forward slash cheese.
So this shows you how quick the Cloudflare settings propagate right.
So we changed the DNS record from gray to orange and within a matter of like five seconds, if that, the page rule was working.
So our network is very quick on changes you make in the dashboard.
So it's just, I just think that's amazing to be honest.
That's why I like to highlight that. So as we can see from that, it works.
My page rule now works. Okay so let's say instead, so that would be me showing you when something was gray clouded and it not working right.
That's one of the simplest fixes.
It's just orange clouding something. But let's say we want to do this.
So let's say we want to go to old blog.csuptv.com forward slash, I don't know, let's say main.
Let's say we don't want this one to redirect.
We just want this one to, we want this to redirect somewhere else.
So if we then go here, we say this exact thing, we want this to redirect.
So let's do forwarding URL. And then we want to change the status code to permanent in this case.
And we want it to go to, where do we want it to go to?
Let's say https blog.csuptv.com forward slash admin.
So let's say we just wanted to do that. Let's save and deploy that one.
Okay, so now this is only on the HTTP.
Remember, I didn't, I added the, the prefix.
So if I do that instead, it will catch both HTTP and HTTPS.
Now, if we go to this in the browser, it doesn't do what we asked it to do.
It's still hitting that first page rule. It did do what we wanted to, it didn't do what we wanted it to do.
But if we move that down there, then it will be different.
What do you mean? What did I do wrong here? I think it just needs time to propagate.
Give it a second. So we've reopened that and it's redirecting to blog.
It's not going to the forward slash admin, which is interesting, right?
So I wonder why that would be. So if we try and go back to it again, and then go open up in there, it's redirecting to main again.
That will probably be to do with caching. So if I go back here, because the 404 is actually cached, but we can, we can alleviate that by clearing the cache, et cetera, like I've showed you previously, and we discussed before.
So if I go to caching, configuration, purge everything, and just purge it, this will then work.
So if I then go back to my slides for a second, we can just talk about a couple of things here.
So you should always, a good rule of thumb is to make sure the DNS record you're trying to run, the page rule is orange clouded, triple check your matching pattern to make sure it matches exactly what you want to do.
Purge the cache if in doubt, if this has to do with caching settings or speed, you know, like enhancing images with polish, et cetera, purge the cache.
And check if there is a page rule priority mismatch as well, would be the best way to get that done.
Another thing, so DNS, orange versus gray clouding.
So what are the differences here?
So a TLDR, orange cloud DNS records are running over the Cloudflare network, as I said before, right?
And gray clouded DNS records are not. That's it really, that is the TLDR.
So I've gone into a bit more explanation down the bottom here. So you can see gray clouded, it's DNS only, your origin IP is exposed, you have no performance gains using the Cloudflare network, you have no security gains using the Cloudflare network.
It's useful for services that don't need protection, services such as email, FTP, non-HTTP based services.
But now we've got like things like Spectrum, et cetera, which can cover these services now.
So even that is protectable over Cloudflare using additional products.
But in the DNS scheme of things, you shouldn't really orange cloud those because it will break things.
You won't be able to FTP over it because it's masked by our IP and FTPing to our servers isn't going to get you anywhere.
So orange clouded means you're going over the Cloudflare network, your origin IP is masked, means when someone tries to look up your origin IPs, they're going to see the Cloudflare network IPs and not your IPs of your origin.
So you have all the Cloudflare features available with an orange clouded record and it's used on DNS records that have web appliances, websites, et cetera.
So that's the main things you need to remember. Okay, so mixed content issues.
Why don't I have a padlock on my site even though it is over HTTPS?
We do get this question quite often and this is mainly due to this mixed content issues.
So it's a security measure that browsers implement where even though the main website itself did load over HTTPS, it loaded resources into it like pictures or style sheets or JavaScript into the page that were not over HTTPS.
So as you can see from my example here, the resource itself is being linked as HTTP forward slash forward slash instead of HTTPS.
So that's where the issue is and I can show you that in real time to show exactly why that is a bad idea and how to get around things like that.
So if we open up this page which you can see here and then we go to csuptv.com itself.
Right now it's not secure.
That's because I loaded over HTTPS. If I change that, now we're padlocked.
So what I did there is I just at the beginning set HTTPS. By default it went to HTTP but now we're over HTTPS.
This web page has the padlock rate because it's just plain text, right?
It's just got this paragraph here, this sentence here with two links.
So nothing insecure about that. So we get the full padlock. So if we click on this page, I'm going to click on the first link by holding control of my keyboard so it opens in a new tab and I click on it.
We can see this is an image below, the image loaded and we've still got a padlock, right?
Perfect. If I then click on this flexible one and then click here, it says not secure right?
So I didn't name this flexible for a reason.
It was just during my creating HTML file, I just named it that for some reason.
It doesn't mean anything. But as you can see here, it says not secure, plain and simple, right?
The full one, come back to that tab, we can see we're on HTTPS, got a padlock here.
If I go to this one and click here, we press left, this is going over HTTPS as well, but it says not secure.
Why? Let's find out. So if I right click on the web page anywhere, go to inspect again, bringing up our lovely dev tools that we love to use here.
And if you go to the console, we'll see here, mixed content, the page at HTTPS, csuptv.com forward slash flexible.html was loaded over HTTPS, but it requested an insecure image.
And then it links off here, HTTP, see, HTTP forward slash forward slash csuptv.com forward slash image, blah, blah, blah.
So this whole image was loaded into the web page over HTTP.
There you go, that's the answer. So customers with these type of issues where it says not secure, and you are in fact going over HTTPS, is probably mixed content, like 99%.
Like, that's what we see all the time. And you can see it like this.
This is how you could diagnose, find out exactly which resource it is.
And then there are a couple of ways to fix. The quickest fix would be to enable a quick fix that fixes the majority of these issues, is to enable a flag in the Cloudflare dashboard.
And that's accessible in the SSL slash TLS tab, called automatic HTTPS rewrites.
So I've opened the Cloudflare dashboard backup.
And if we go to the SSL slash TLS tab, and go to edge certificates, scroll down, you'll see the setting for automatic HTTPS rewrites.
As you can see near the top of my screen now, automatic HTTPS rewrites is there, and it is turned off, right.
So it being off means it's not going to try and fix anything.
So you can see by the description of the feature, automatic HTTPS rewrites helps fix mixed content by changing HTTP to HTTPS for all resources or links on your website that can be served with HTTPS.
So it does say helps. It may not get all of the resources that are loaded in securely.
But in experience, nine times out of 10, enabling this will, you know, fix the issue.
You should still, after you've enabled this to get a quick fix to get the padlock back, is fix your origin website, like your website itself.
That could be if it's like a WordPress website, there are plugins.
So on a WordPress website, you can WordPress plugin insecure SSL.
I think it's called that. There you go. SSL insecure content fixer.
So as you can see at the top of my search, that's one of the major factors that you can do to fix your WordPress website, is to install that plugin and, you know, go for its normal feature set and options and fix it that way.
But that means if you break your website running any plugin or anything I'm showing you here, that's your fault.
Okay. I'm only showing you for my purposes of this and it does work.
Just make sure you take a backup before you install any plugin. Make sure it's compatible with your version of WordPress, et cetera.
You know, do your due diligence and have a backup just in case.
I myself have never had issues with this plugin.
So it works. And you can see from the rating here, it works and it is free.
So yeah. But yeah, if you don't use, like not everyone uses WordPress, right? So there are, if it's like a proper static website, you're going to have to go into your code to fix the problem.
But for now, what we're going to do is I'm going to enable this flag here.
If I just press on, this setting was changed a few seconds ago.
And then if we go back to my webpage, which had the insecure thing, it's closed DevTools out.
And now just refresh. Let's do a full empty cache and hard reload.
There you go. I fully refreshed the page.
Let me unzoom that a bit because this is hard to read. There we go. As you can see now, we have the padlock back.
What I did there was it wasn't working and it showed the same image when I refreshed.
That's because Chrome was caching the previous request for the image.
So all I needed to do was just right click empty cache and hard reload.
Like these extra options in Chrome only come up when you have DevTools open.
So like if I close DevTools and try and right click, I'm trying to right click now on that refresh button and it does nothing.
So just open up the DevTools and then right click on the refresh button.
You got normal reload, hard reload and empty cache and hard reload.
So with that reloaded, we can now get, we now have to padlock and the source code.
So if you view page source, which just brings up this, it shows you the code of the website, right?
You know, the HTML, etc.
And we can see here it shows as HTTPS. Okay, so that shows us HTTPS even though my website does not have that set.
It does say HTTP. And if we go back to the Cloudflare dashboard, I'm going to turn that back off.
Then go back to the source, back to this page showing the source of that page that was broken, but was fixed with the Cloudflare dashboard stuff and refresh.
Let me do this.
We can now see it shows the proper HTTP. Again, I did the force hard reload, etc.
just to get this to show up because Chrome is caching again. We can see that this shows us HTTP, right?
So my origin shows that and if we go back to flexible, refresh, it shows it's not secure.
So what is the proper fix here? The proper fix is to fix it at your origin web server.
So right now, you should be able to see my terminal window, which is logged in to a server that is running that web page.
So if we go to the actual HTML page and we edit the file, flexible.html, we scroll to where that is in the source code of the site.
Here it is. We see it here. Image source HTTP.
So right there in my website's code is the issue. So most people probably wouldn't use their terminal to fix this issue.
They may be using FTP client or SFTP client or a CMS like Deluge or Magento.
There's loads of different avenues where this can be fixed.
Most of those CMSs, content management systems, do have plugins to fix it.
So install the plugins that exist for that or manually fix.
So the manual fix here is add an S and I can control X, press Y, hit enter. That saves my changes.
So if I reopen that file, go back down there, we can see it shows as HTTPS again.
Cool. That should now be fixed, right? So if we then go back to flexible here and hit refresh, boom, we have the padlock.
And if we go back to the view source and hit refresh, boom, HTTPS.
So that is the true fix. The true fix is fixing at your origin web server.
It can be fixed by using that Cloudflare dashboard switch for automatic HTTPS rewrites.
But in the long scheme of things, you should probably fix your origin, right?
So those are the ways in which it is really handy and helpful for you to fix issues yourself in regards to mixed content.
And I hope that was helpful. So there we go. You could also, as it shows here, instead of writing HTTPS for the resource, you can do just forward slash, forward slash instead on the resource itself inside your source code.
And that will make sure it will load under whatever protocol your website is loading under, right?
So if you load the website under HTTP, it will load the resource under HTTP.
If you load it under HTTPS, it'll load on HTTPS. So there's two ways to do it.
I just showed you the simplest, which was just changing to an S from without an S.
Moving on. So is a site using Cloudflare? Probably. So there are several ways to check this.
Easiest way is a Chrome extension called Clare. So if we go here, oh, I do not have it enabled on here.
Give me a second. Let's try enable it.
Extensions. There's Clare. You can label it on. I just can't remember where you enable things to be.
Allow in incognito if I tick that.
Then we go back to here. And now we see we have this gray cloud that's appeared, which is the Clare extension.
It doesn't show, it shows straight away for all loaded tabs, right?
So I've installed the extension and it shows an orange cloud for csuptv.com.
Perfect. And if it's not on Cloudflare, that will be gray. It'll be a gray cloud instead of an orange.
So it's really great at a quick reference to see if your browser on your computer is now seeing the website over Cloudflare or not.
So notice I didn't say it will show you if your website is active on Cloudflare.
So because your website could be active on Cloudflare, 100% fully working, but your local computer may be caching something or Chrome is caching something, showing it still is gray.
So there are avenues of interpretation there. But if all else fails, full refresh using the clear cache trick I showed you does the trick.
So if you reload it like that as well with Clare recently installed, it shows you more information as well.
So if I click on Clare, misclick Clare there.
I'll drag my window instead. Give me a few moments. So if you click on Clare, it brings up this.
So it shows you if they're using IPv6, if they're using Railgun, if it's HTTP2 request, the IP address you're hitting, which is going to be the Cloudflare edge server.
I'm on IPv6. So I hit an IPv6 IP, which is one of Cloudflare IPs.
You can see the RAID as well here. So again, another great troubleshooting trick.
And it shows you the RAID there, which is easy to copy.
So this little copy symbol here, that's now in my clipboard to copy to support or my web developers or whoever.
The location as well shows you San Jose.
So this shows you exactly which data center you're hitting. There's also another great thing here called trace.
So if I click this button, it opens up this, which then shows you, that opened up in a new window.
Give me one moment. As you can see now, I'm showing you the CDN CGI trace from where I clicked in Clare.
It now shows you this whole trace information.
So in support, we do ask for this information.
So if we ever ask you for a CDN CGI trace, this is what we're after, the output of this, because it shows you, like, FL means which machine are you hitting?
Host, which host you're hitting, right? CSTV.com. The IP, the exact timestamp of this exact request.
So where you are, if it was HTTPS, your user agent, the colo you're hitting, the location, the TLS version you're using, and SNI warp as well.
So it has a lot of information that we can use to start a diagnosis process, diagnosis.
So one of the main ones we love is knowing which colo you're hitting, really.
So if it's a regional thing, you're having a regional issue, we can then dive into that region or, you know, the exact timestamp.
So you give us a timestamp and then we can look back at that timestamp or around it to see if there was any issues around that time, etc.
So it's all very helpful information. So please try and give it to us when we request it.
Or even when you're opening a support ticket, including it can't hurt, right?
So just running a CDN CGI trace will help.
Even if we haven't explicitly asked, open your ticket in preempt of the questions to ask this.
So if you just send it in for us, it helps. So I'm going to head back to the slides for a second.
As we can see, Clare, I've explained Clare. It's probably the best way.
I have it installed. Loads of people have it installed just to see at a glance if a site is using Clareflare.
It's very, very handy.
You can also check the headers. So you know before when I showed you the curl, the curl request, bring that back up for us.
If I go back here, I mean we've run this curl before right up here, which is a curl.
It's just like doing a request in terminal to a website.
These are all the reply headers we got back and some of them are very Clareflare specific, right?
So we've got starting from the top down, Clareflare specific one.
We've got the CF UID cookie. That's very Clareflare specific. CF cache status, that's a Clareflare header.
CF request ID, Clareflare header. Server, Clareflare.
That's a big clue, right? So that's a good one to see if a site's on Clareflare and the RAID ID as well.
So just check the headers. If you ever see anything that's Clareflare related, it's probably on Clareflare.
So I'm going to go back to the slides for a minute.
So you can check the IP address against our list of IPs.
So what that kind of means is, so yeah, point three, as you can see here, point three says check IP address against our list of IPs, which means the IP you're hitting here, right?
If it's an orange clouded domain and you're seeing headers here, then this IP is Clareflare's IP.
So you could just check this IP to see if it's a Clareflare IP.
So the way you can do that is by, so if we open up a browser, let me go to clareflare.com forward slash IPs.
These are our IPs. If I go to control F paste, obviously it won't show the whole IP, but we can see 26064700, 26064700, and there's the 32.
So the IP matches our IP set. Easy. Yeah.
So if you're orange clouded, you're going to get these results. And if you're gray clouded, you're going to find that the IPs and the headers, et cetera, you get back won't have any connotation towards Clareflare at all.
So 5XX error, is it Clareflare?
Okay. So we do have many, one of our major things we have is people writing in regarding their website, throwing 5XX errors, such as 503, 502, 521, 522, et cetera.
The majority of these are origin-based issues and our knowledge base at support.clareflare.com details how you can check yourself if it is a Clareflare issue or not.
Most of the time, it's not a Clareflare issue. Sometimes it is, right?
But you can check yourself prior to opening a support ticket to save yourself time for one, and us.
So by checking a few things, just checking the support articles, you know, support .clareflare.com, and then writing in 522, for example, or whatever error you're finding, it will go over the steps you could do and what would be displayed if it was a Clareflare issue versus if it wasn't, and things like that to help you on the right way to, one, open a support ticket if you can't find the issue and you need us to help you, which we'll happily help you figure out exactly where the issue is.
Beyond, we don't help you with origin issues specifically, but we will point out if we can prove that it's something to do with your origin, like your origin web server, so then you'll be able to, you know, reach out to your web host and get them to fix it, or your web developer, or your server administrator, etc.
So things to check. With nearly all 5xx errors, you should check to see if your web server is up and running.
If it's not, that's your issue.
If it is, maybe it's something else, but you should still look through our troubleshooting guides and our knowledge base to go through how to do that.
Check your firewalls are not blocking Clareflare. So sometimes it's not like a full block on all requests.
Maybe some people are having issues sometimes and they're getting this specific error message.
Maybe your firewall is only blocking one of our hundreds, thousands of IPs, right?
So if it's only blocking one or a subset of them, then only some of your clients that are going to your website would experience issues, not everybody.
So that's where you should just double check your firewall configurations to make sure none of them are in blacklists or anything like that, and no one has inadvertently blocked them.
So you should always also make sure your SSL mode, so like full, flexible, off, etc, match what your origin web server expects.
So if you're expecting HTTPS requests, they're using full, etc, it's perfect.
So I'm just going to show you one quick way of...
I'm just going to show you an example error. So let's open up csuptv .com.
Maybe not in this window.
I'm going to... I pressed the wrong button there. There you go, I'm back.
So as you can see, if I go to csuptv.com, we see this. If I then...
it's all working, right? I refresh, everything's perfect. If I then log into the server, and now I'm going to do a...
I'm trying to remember which web server I went with for this one.
Yeah, it was Nginx. So if I then run sudo systemctl stop nginx.service, that stops my web server.
So the web server on this website is now down.
So what error do we expect if I refresh this? Let's see. 5, 2, 1. Web server is down.
We're quite explicit when it comes to our errors, and we usually show you in the area here in the middle.
So you see on the left we've got browser, in the middle we've got Cloudflare, and on the right we have host.
And the first two have green ticks, and it says working.
And on the far right it says error with the host, right?
That means it's not us. A 5, 2, 1 is not Cloudflare. So what happened? This is the error message being really helpful for you as clients.
The web server is not returning a connection.
As a result, the web page is not displaying. So what can I do?
If you're a visitor, they just need to wait, right? If you're the owner of the website, contact your hosting provider, letting them know your web server is not responding, and that we also link off to our support articles.
So if I open that, it links off here, and it will scroll down to the 5, 2, 1 automatically, right?
So I clicked the error message. So the error message shows you a link to troubleshoot your own issue.
So it shows you for a 5, 2, 1 security solutions that your origin may block legitimate connections, along with, you know, the web server being down.
So the two most common offline origin web server application. That's what we did here.
So resolution, fix it, right? It's not Cloudflare thing. We can't help you.
Like, literally, like, there's no way we can fix this issue for you.
So make sure, like, when you're looking over these guides, we try and help you in the best possible way.
And we're not trying to, you know, you know, we're not just brushing you aside.
We're trying to give you really helpful information inside of our error messages that link off, usually, to a good support article to get you on your way to fixing your issue.
So if I now go back to my web server here, and I then change that to start, so I'm going to turn on my web server again, and then refresh this, we're back up.
That's it. That's how easy it is to fix that kind of issue, if you know exactly what's broken.
So obviously, the rabbit hole of what the issue is can be harder for a client, especially when they need to talk to a server administrator who then needs to talk to someone else, you know, it can be hard.
But if you can give them the information that it is somewhere in your web stack, then you can try and get them to fix it in the quickest manner.
A similar thing, like for most of these, so we have an actual section for all of these.
And these will all help you when you have the issue, look up on our support article, click the links in the error message to see if it takes you on your way to diagnosis and resolution, because we do try our best here to update these and keep them fresh regarding how to fix your issues.
So back here, so I've covered everything here, 5xx errors, is it Cloudflare?
Sometimes it is, majority of the time it is not, and we will help you if you need it to point out where the issue is.
But always remember that our error messages usually link off to help you diagnose your own issues, etc.
How can I block an IP address is next, and I'm going to be really quick on here, nine minutes.
So there are several ways to block IP addresses, IP firewall or firewall rules.
Simple enough, right? So really simple, let's say you want to, let's just say there's some bad IP that you really want to block.
They keep spamming your forum or whatever, and you just want to blanket block them from all of your websites.
You can just go to tools, and as you can see here, I have a block on this IP.
I just entered it randomly, it doesn't mean anything. So this website, block, block, and it will block from just this website.
So any requests to csuptv.com or blog.csuptv.com or any subdomain of csuptv.com will be blocked for this IP address.
That's it. IP access rules are very, very heavy-handed, right?
So IP access rules, heavy-handed, keep that in mind. But you can also, here, when you enter the IP, so I could have done a block for all websites in account, so this will block them, that specific IP for any websites I have under this account.
A better way, I'd say, to block IP addresses is this, using firewall rules.
It's better, right, because it's more granular. You can have specific conditions to be met before someone is blocked.
There's a plethora of things you can do.
So let's do a test block, let's do IP, so you can do IP address, but you don't actually just need to do IP addresses, you could do AS number, so like the AS of a specific provider or region or whatever, or country, so you could block a country or things like that, but you don't actually, it's not just block, so you can then choose an action.
So let's say for the IP address of 1.1.2.2, whatever, we can do a block on the IP and that will just block them for any request to csuptv .com or any subdomain etc, or we can JavaScript challenge them, that's the I'm under attack mode page, or we can challenge capture them, actually they would have to enter a capture to go to your website, or we can allow them, or we can bypass, which means you can bypass features, or we can just log the request.
So that means if you just want to log the request, so whenever this client would go to your website, it will show in the file events here, so whenever that client went to the website, it will show up here as a log entry, not a block.
So yeah, file rules is the way to go, and it's the best way to granularly set.
So let me just do a quick test block, and I'm going to do the IP address just quickly as same, but then we can do and, so two conditions need to be met.
So we do URI full, let's say we just want to block them from a certain blog post, so do blog, that was bad spelling there, blog.csuptv.com forward slash article one, and we want to block them from that.
So this will mean this IP will only be blocked from accessing that exact article, maybe they're spamming it and you just want to make them stop, that kind of thing.
So it's super granular, there's tons more to this, you could have a whole session on this for at least an hour, and still not cover everything.
So that's just a really brief, how do I block an IP address, showing you the firewalls is the way to go if you want to be granular, and IP access rules is more of like heavy hitting blocking.
So error too many redirects, hugely common request from customers, they onboard onto Cloudflare, they press some buttons, and they go to their websites, and they get the error, error too many redirects.
Let me show you what the error looks like. So I go here, and we go here, we change the SSL mode to flexible.
So I've now set the SSL mode to flexible, which means my origin is only going to get requests over HTTP, right.
So what I do here is if I go to csuptv.com, it loads for some reason, that's because I'm going over that HTTPS, do that, it's still working.
I thought I put redirect in to stop that working, give it a minute.
Let me just see, maybe it was a different URL.
Okay, so that should have blocked access to the website based on my origin, but I think I may have fixed it during my fiddling earlier, so which would be on this one.
So if I go to blog.csuptv.com, it is trying to load, and I think this is the redirection.
So if I go to blog.csuptv .com, issue. Here we go, perfect. So here we go, error, too many redirects.
So what this means is Cloudflare is trying to connect to the origin for blog.csuptv.com over port 80, and my origin is automatically redirecting to HTTPS, because I've set the redirect at my origin to only accept HTTPS traffic, but then it goes back to Cloudflare, and Cloudflare says no, they want flexible, which means I need to talk to you over HTTP, and they're talking over HTTP to the origin, the origin goes no, I want HTTPS.
So you see, that's the circle.
So that's like the redirect loop happening in that way, and it happens quite often, where the origin is set up to only accept a certain type of traffic, and you misconfigure the SSL mode here.
So you should always make sure that the SSL mode here corresponds to what you need based on your origin.
If I set it back to full, my origin should now be happy, because it's doing HTTPS to the origin, the origin says great, and it just carries on, and that's the end.
It doesn't keep redirecting, asking for other type of traffic.
So if I refresh this, being a bit slow on the fix here, there we go, boom.
So now csuptv blog is now back up.
As you can see, so I've got two minutes here, so I'm going to move on from that, but redirect loops are a thing, and that's like, you just need to work out what your origin web server is doing most of the time, and adjust the SSL mode to match what your origin is expecting.
If in doubt, change the SSL mode, wait a minute or two, and refresh your page to see if it works.
Try that different times with changing to flexible, changing to full, and it will usually fix your issue, nine times out of ten.
I'm going to finish on giving support enough information, but I've only got like less than a minute now, but I've already explained everything that you need to give during this whole presentation, include a HAR file, replication steps, make sure you give array IDs, or the trace, cdncgi trace, etc, etc.
So just make sure you give us all the information that you think we'd ever need to diagnose the issue, as if we were blind.
Imagine we're blind, and you're trying to give us all the information to understand your issue, because we are effectively blind.
We don't know your settings, right? Cool, so that's the end of that.
So I covered all these topics today. Thank you for watching, and I look forward to doing this again, covering other things you have.
Feel free to reach out to live studio at Cloudflare .tv with additional questions, what I might cover in the next session.