In this previous post I showed how you can set-up a custom domain in Azure and link that to your app service. Here, I’ll cover how you can add Cloudflare as a reverse proxy to your Azure site.
Start with Cloudflare
For the purpose of this post, I’ll assume that you have a Cloudflare account. I believe that everything in this post can be accomplished on the free tier. The first step is to add a new site to Cloudflare:
It’ll ask you for the URL of your site (you must own the root domain of your site). When you add your new site, you’ll be presented with this:
In order to make the changes that Cloudflare suggests, you’ll need to jump to Azure.
Over to Azure
In the Azure Portal, navigate to your App Service Domain (see the previous post referenced above for how to create this):
In the domain registration, you’ll need to select Manage DNS records:
Here, you can see the DNS entries for the domain:
As we saw from the Cloudflare recommendation, we’ll need to change these; although annoyingly, you can’t change them in this blade.
Advanced Management Portal
To change the nameservers, in the App Service Domain, go to Advanced Management Portal:
In here, select your domain:
Select Manage DNS:
When you update this, it may take up to a day to change (although it can take a few minutes).
Imagine a situation where your web-site is being linked to, or referenced, such that the case of the URL differs; or, for example, where you wish to change a given part of the URL. Let’s use the following URL from my site as an example:
One possibility in Cloudflare is that you could set up a custom redirect rule (i.e. just create a new rule that redirects from the address above to the lower case version; for example:
But what if you have dozens of such examples, and they all differ very slightly. I’ve been playing a little with a new(ish) Cloudflare feature called Workers.
In this post, I’ll cover getting started with Workers, how to use one to perform some custom logic on your URL, and link that to your domain.
The tool that you’d use to set these workers up is called Cloudflare Wrangler. To install Wrangler:
npm install -g @cloudflare/wrangler
Once installed, execute the following to ensure that you’ve correctly installed it:
The next step is to log-in to your Cloudflare account from Wrangler:
That will ask to launch the browser, and get you to log-in:
Once you’ve authorised this, you can create your new Cloudflare Worker project:
wrangler generate wrangler-test-1
This will generate a project folder in the current directory:
Once this is done, take the Account ID (shown above), and open the wrangler.toml file that has been created within your project. Set the account_id in there:
name = "wrangler-test-1"
account_id = "f8021e056d0d5e96c9b3ba4ad054bb2c"
workers_dev = true
route = ""
zone_id = ""
You should now be able to debug this locally by typing:
However, if you run that at this point, you’ll most likely get a 500 error:
Error: HTTP status server error (500 Internal Server Error) for url (https://…
The reason you’ll get this is that you have yet to set-up Workers on your Cloudflare account.
(It’s worth bearing in mind that, whilst there is a free tier, Cloudflare workers can cost money after a given number of requests.)
In your Cloudflare account, select Workers and click Set up:
Now that Workers are set up, you should be able to resume:
This looks like it’s running on localhost; which, in fact, it is; however, all the requests are being proxied through Cloudflare (and so the worker will execute on their servers).
You can also simply publish your worker, like so:
As you can see, this gives you a specific Url to navigate to. The default example allows you to display “Hello World” based on the request.
Write the Worker
Up until now, we’ve just taken the default worker code; but what about something such as the following:
All we’re doing here is checking is the URL is lower-case; if it’s not then we make it lower case. Obviously, if you execute this on its own domain, the worker will not respond, but you can then map this to a different domain; for example:
Now, all the requests coming into pmichaels.net will be manipulated, and then passed through. If we map this and re-execute the initial request:
It’s worth bearing in mind that this executes on all requests to your site. For example, say you did something like this: