Yesterday, Today on the Cloudflare Community

Welcome to Yesterday Today on the Cloudflare Community. I'm your host, Tim Cloonan. If you'd like to know more about the Cloudflare Community, join us every Friday for a new edition of Yesterday Today. Each week, we start by looking at a summary of popular topics and site traffic from last week with this Community Day and the Community Traffic Report starting at 10 a.m. Pacific. That's followed by a review of top community issues from last week, the ever informative Using the Community Tip, occasional interviews with Cloudflare MVPs, employees, and partners. And every week, we feature In Class with Cloudflare, where we learn a few things from the community and we put them to use in a Cloudflare Community Tip. Turning to the traffic report, overall community traffic was flat versus the prior week, with new posts up significantly, but with new topics also flat versus the prior week. This basically means about the same number of people spent more time talking about the same number of things. The number of new customers joining the community was up week over week and remains up dramatically for the year. As a reminder, the Cloudflare Community at community.Cloudflare.com is a free service for all Cloudflare customers where you can seek advice and insight about using Cloudflare. Join today, learn forever. For this community day last week, the top three searches on the community were regarding the 524 timeout error that we've seen come up pretty frequently, SSL, which in and of itself isn't really helpful to tell us what folks were searching for, but we're going to dig a bit deeper and see what those searches meant in just a moment. And finally, Google Analytics, which does also not tell us a whole lot about the nature of the search, but we'll look deeper into that data in just a bit as well. The most popular category for discussion on the community last week was again the security category, with questions about the WAF leading the discussion. We had the same results in our last two shows, and as a result we will be talking about the WAF on future episodes in greater detail. Activity in the security category was followed by the second most active category of performance, with questions about cash leading the category. The final top category was the DNS and network category, with questions about main servers again leading that category. And that leads us to our top stories today. This morning on Yesterday Today on the Cloudflare community, we'll look into resources to troubleshoot those top three issues from last week, and we'll spend some time talking about very specific activity that happened in the Cloudflare community last week. Before we dig in, let me invite you to join the show today, submit your questions to livestudio at Cloudflare.tv, or hit the email into the show button on Cloudflare TV, and let us know what's on your mind. Before we begin our show today, we've done a series of episodes regarding the Raspberry Pi, and we looked at how Cloudflare customer support is using the Raspberry Pi to train new technicians, we looked at how Raspberry Pi can be used to test setup in Gateway, and we talked about running OneDot for Families on a Raspberry Pi. And we had set up a Raspberry Pi OneDot router to protect my local network at the studio here. In doing that, we explored a lot of different options with the Raspberry Pi. And one of the things that came up was quite interesting, is that we had to cancel one of our shows, because the production studio where we broadcast was smoked out due to the fires in Northern California. So as a result, we grabbed some of the Raspberry Pis that we had used for those shows, and we actually reformatted them and set them up as air quality sensors. So if you think that the Raspberry Pi is just a fun toy for your kids to play with, it's actually one that can help protect your family and protect you in a number of different ways, either from running OneDot for Family, or in my instance, running an air quality detector to tell me if it's okay to leave the windows open or not. So break out your Raspberry Pis, give Cloudflare Gateway a try, try OneDot for Families on the Pi. And if you're in Northern California, you may want to consider setting up an air quality station as well. Now, on to our show. First, let's talk about the questions from the community search last week. And we'll offer a couple of different pro tips for each. The 524 timeout error. This is an origin error that indicates that Cloudflare made a successful TCP connection to the origin, but the origin didn't reply with the proper HTTP response before the connection timed out. So typically, Cloudflare is going to wait 100 seconds for that response. If the origin doesn't respond in the time, Cloudflare closes out the connections, and then your visitors see the 524 error. It's a frustrating error. And we sense that on the community when folks post about it. As we begin to troubleshoot, we understand that there's a lot of nuance to the error, and it can be difficult sometimes to troubleshoot. But typically, it starts out with customers not understanding why they're seeing a 524 now when they weren't seeing a 524 yesterday before they had signed up and put their site onto Cloudflare. I suspect what's happening is that the visitors to your site were waiting. They just didn't have the option to throw a 524 error. So they were probably waiting in excess of the amount of time for the process to complete. There are some quick and easy steps to get rid of the 524 errors. If you assume that your hardware requirements didn't increase dramatically without reason, which they shouldn't have, then what you should do is to look at the load balancer and server issues to make certain that you're investigating first things first. What you want to check to make sure that the resources are reliable, there's no memory errors, there's no disk errors, and that the systems are generally performing as you would expect it. You want to make certain that there are no processes that are overloaded as a result of any hardware defects that you encounter. You also want to chase this through the entire set of connections. So if there's a process that's offloaded to another server like a database, for example, you also want to check the logs on that device as well, because it could be that device that's throwing the 524 error. There are some indications of the errors, and you'll start to see them in those logs, and that's the first place that you should begin to look. There are other quick fix ideas on the 524 errors. Go to the community.Cloudflare.com, search for 524 and hashtag community tip, and you'll find a community tip with other quick fix ideas. The community tip for the 524 issues has been used about 100,000 times by members and visitors to the Cloudflare community. If you have a 524 error, it may be able to help you as well. Next. Visitors to community.Cloudflare.com search for SSL. Looking deeper at the search data and click-throughs, we notice that most of the SSL searches were actually related to mixed content issues. We've talked about mixed content in depth on one of the episodes and tangentially a couple of different times on the show. And if you recall, mixed content errors basically mean that your website's being loaded over HTTPS, but some of the resources that are being called are being loaded over HTTP. In this case, the site shows it's not secure. So you have a site, you have a certificate issued, the site normally loads in a secure way, you hit a page, it calls for a resource that's not secure, and all of a sudden your customers feel that your site's not secure. Here's the thing about mixed content. It can either be a very, very simple error to fix or it can be an incredibly frustrating one to chase down. Domains that are added to Cloudflare receive SSL certificates so that they can serve traffic over HTTPS. So some customers notice that these missing content or page rendering issues when they first serve HTTPS traffic. If you think things like, my page looks weird or things are missing, those are pretty good clues that you're dealing with a mixed content issue and that should be the first thing that you investigate. To see mixed content, because what you'll see is the error but not the sign of the mixed content, simply use Google Chrome, Developer Tools, Console View, and the mixed content errors will be very, very apparent. Typically mixed content's due to a request for this HTTP resource from a webpage that is being served over HTTPS. For example, if you type in HTTPS example .com in a browser and the page contains that image reference via HTTP, the image of your cat fails to load and the browser shows that your site's not secure. Each browser and each operating system seem to have their own way of communicating these errors to the visitors. One of the most common symptoms of the mixed content error is that the lock icon on the left side of your address bar starts to appear different than the normal trusted green lock icon that you're probably used to. At its simplest, you can use the Cloudflare dashboard setting of automatic HTTPS rewrites to correct code on your site before it reaches your customer's browser. But, automatic HTTPS rewrites have limitations and this is where it could get complex depending upon how comfortable you are with editing HTML. Before the rewrite gets applied, the HTTP resources are checked to ensure that they're accessible securely via HTTPS. If a resource isn't available over HTTPS, Cloudflare can't rewrite the URL. You can test this yourself. Using the Google Chrome developer tools, you can find the line with the reference to the insecure asset. Copy that URL, change it to HTTPS and paste it into an address of a fresh browser tab. You can check and see if that asset's available to load using HTTPS. If it is, then the asset's available. You simply need to change the code on your site. How you change the code on your site is going to depend upon how that code is being introduced to your site. Sometimes it may be done via JavaScript, which gets a little bit more complex. If it's simple HTML, then those HTML rewrites are going to work for you. Let's talk about those issues loaded via JavaScript. When these issues are loaded via JavaScript or CSS via HTTP when the site's in a browser, in those situations the mixed content warnings still appear on the left side of your address bar showing the broken lock. In addition, for scripts, you're going to see a telltale icon on the right side of your address bar. This in Chrome is going to look like a small shield with an X on it. If you click that shield, it's going to give you the option to load the unsafe content or run these unsafe scripts. That's fine for your site for testing purposes so you can understand the impact of the missing script, but it's not something that you would expect a visitor to your site to do on a regular basis. In no way should you ask them to do that. There are other quick fix ideas for mixed content in terms of how to edit the CSS and the JavaScript files to make the calls relative versus absolute to sidestep these mixed content issues. What I'd encourage you to do is visit community.Cloudflare .com, search for mixed content hashtag community tip, and the mixed content questions that you have will be documented in this community tip quick fix ideas and you'll be able to navigate through and fix those issues on your site. For more quick fix ideas, we can also encourage you to post on the community and ask. Mixed content comes up probably every day and the community is very well versed in helping you to troubleshoot it. Next, our third most popular search topic on the community last week was Google Analytics. We see discussions around Google Analytics frequently in the community. Typically, the focus of the post is why is the traffic data I see on my Cloudflare dashboard dramatically higher than the traffic data that I see reported by Google Analytics. In any analytics discussion, it's really important to understand how the data is collected. Cloudflare proxies traffic to your origin web server. Therefore, the Cloudflare connecting IP address matters only for any stats applications that read logs directly from your web server. You can think programs like AW Stats, for example. However, since Cloudflare doesn't proxy Google traffic, we have no effect on your Google Analytics tracking. Your site visitors interact with Google servers directly. The Google Analytics JavaScript code that you've embedded on your pages is going to be executed by the user's browser. So the Google Analytics sees the IP of the user's browser. The Google Analytics JavaScript code on your page doesn't talk to your site, so it doesn't interact with Cloudflare. But the stats results are going to be different. As pointed out in the community, Google Analytics is a tracking script. And I'll quote directly from the post because it netted it out pretty well. Depending upon your visitor base, it may be very likely that they have an add block, unblock origin installed, preventing the tracking script from recording the page view to Google. Cloudflare Analytics is server-based, meaning no matter what, a user visitor will be tracked in the dashboard. So it's very possible and to be expected that your metrics in Cloudflare dashboard will not fully align with the same site data as reported from other sources like Google Analytics and web server logs. Once Cloudflare identifies a unique IP address for a request, we identify that request as a visit. Therefore, the number of visitors in Cloudflare Analytics is probably going to be a lot higher than what these other analytic services are going to report. For example, Google Analytics and other web -based analytics program use that JavaScript on the web browser to track visitors. As a result, Google Analytics isn't recording any sort of threats, bots, or automated crawlers. Those requests don't typically trigger JavaScript. So these services don't track visitors who disable JavaScript and also they leave a page before it fully loads, so they're not going to be tracked either. So there's a lot of variation and discrepancy in how these are going to be recorded. To net out an Analytics pro tip, it's very likely and expected that user visitor data from the Cloudflare Analytics app is greater than the site analytics unique page view as reported by Google Analytics. This is because page views reflect when someone visits a page via a web browser and loads that entire page. However, when another site or a service consumes, like a bot or a plugin or an API, if they consume partial content on your page but don't load the full page, this counts as a unique visitor in your Cloudflare Analytics, but it's not going to count as a page view in Google Analytics. So Cloudflare is always going to show more visitors than GA page views. Moving on to our other main story today. Activity on the Cloudflare community last week was up dramatically in a couple of key areas. This was due primarily to the Cloudflare community hosting an internal Cloudflare community jam. In conjunction with community leaders, MVPs from around the world, and over 100 Cloudflare employees from around the globe collectively spent several hundred hours over lunch on Friday answering questions in the Cloudflare community. So a week ago, almost every team at Cloudflare was represented in the community in the jam. This included our executive team, customer support, systems engineering, product management, our engineering team, even our pricing, billing, and policy teams had representatives answering questions in the Cloudflare community last Friday. As part of the jam, the team reviewed over 10,000 posts and were able to resolve 43 open community questions and posted 250 replies seeking additional detail from customers. They also liked or received likes on 750 posts. That's about a thousand and ten percent increase in the number of likes in a one-day period on the community. Likes do indicate that you like content, but they also include you on future posts and conversations around that post. This jam will be repeating in the fourth quarter and so get your questions on the community today as we'll make certain that we go through and we answer them in next quarter. Thank you for joining yesterday, today on the Cloudflare community. I'm your host, Tim Clunan. I'll see you next Friday at 10 a.m. Pacific for a new edition of Yesterday Today. Until then, we'll see you in the community. ... ... ... ... ... ... ... ... ... ... ... ... ... ... Zendesk is one of the world's premier customer service companies, providing its software suite to over 125,000 businesses around the globe. ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...