Redirects and rewrites

Make a site for the old name and set it to redirect. Nothing else is needed.

1. Sites, Add a site.
2. Server names: the old name, for example old.example.com.
3. What it does: Redirect somewhere else.
4. Redirect to: https://new.example.com.
5. Pick a certificate for the old name, tick Listen on https and Redirect http to https.
6. Save, then Apply config.

The path and the query string come across on their own. Somebody asking for old.example.com/products?id=5 lands on new.example.com/products?id=5. You still want a certificate on the old name, because a browser checks the certificate before it reads the redirect.

Do it as a path rather than as a whole site, so the rest of the site carries on as normal.

1. Open the site, Paths tab, Add a path.
2. Path: /old-page.
3. Match it how: Is exactly this. That stops /old-page-two getting caught as well.
4. What happens: Redirect, then type where it should go.
5. Save, then Apply config.

Once a site has any paths at all it stops using the single backend on the Basics tab, so add a path of / pointing at your normal pool as well. The Paths tab says the same thing in a box at the top, because it catches nearly everybody once.

This is the one people ask for most. Visitors use /shop/basket and the application behind it expects /basket.

1. Open the site, Paths tab, Add a path.
2. Path: /shop/, matched with Starts with this.
3. What happens: Send it to a pool, and pick the pool.
4. Tick Take this path off before sending it on.
5. Save, then Apply config.

The visitor never sees the change. The address in their browser stays /shop/basket and the backend gets asked for /basket. Leave the box unticked and the backend gets the whole thing, which is right when the application already knows it lives under /shop.

Two ways, and which one to use depends on whether the visitor should see the new address.

If they should see it, make a site for old.example.com, add a path of /shop/, choose Redirect, and point it at https://new.example.com/. The rest of the address is added on the end, so /shop/basket/items arrives as /basket/items.

If they should not see it, and the two names are really one service, keep them on one site and use a path with Take this path off before sending it on ticked instead. Nothing moves in the address bar and there is no extra round trip.

Permanent is a 301. Browsers and search engines remember it, sometimes for a very long time, and some browsers will not ask you again until the cache is cleared by hand. Use it when the move is final.

Temporary is a 302. Nothing is remembered, so every visit asks again. Use it while you are testing, during a maintenance window, or any time you might change your mind.

The Code box on the path is where you pick, and a whole site redirect uses the same two. If you are not sure, start temporary. Turning a temporary redirect into a permanent one is easy. Getting a permanent one back out of a few thousand browsers is not.

Put both names on the one site, in Server names, and set When it answers to more than one name to Send the rest to the first one. Whichever name you typed first wins and the others redirect to it.

So example.com www.example.com sends www traffic to the bare name, and www.example.com example.com does the opposite. Make sure the certificate covers both names or the redirect never gets read.

The quick version: add a path, matched exactly with Is exactly this, and set What happens to Refuse it. The request is turned away at the load balancer and never reaches your application.

That answers 403, which means you are not allowed. If you want it to answer 410, which means it existed and is gone, put that in Extra config for this path on the same dialog. The difference is worth the extra minute if search traffic matters: a missing page gets asked for again for months, and a page that says it is gone gets dropped much faster.

If the content moved rather than went away, redirect it instead. A redirect keeps the traffic and the ranking. Refusing throws away both.

For a handful of addresses, use a path each. For a whole shape of address, use a rule.

1. Open the site, Settings tab, tick Show advanced settings.
2. Scroll to Advanced and use Rewrite rules.
3. One rule per line: a pattern, where it should go, and whether the visitor sees it.
4. Save, then Apply config.

Check the nginx config tab afterwards. It shows exactly what your rules turned into, which is a lot quicker than finding out from a visitor. A pattern that matches nothing is silent, so if the rule seems to do nothing, that is the first thing to suspect.

A path each does not scale past a few dozen. Use a map instead.

1. Maps, Add one.
2. Reads: $request_uri. Sets the variable: something like $new_address.
3. Leave the default empty, so anything not in the table is left alone.
4. Add a line per old address, with the new address beside it.
5. On the site, use the new variable in a rewrite rule under Advanced.

The table is one lookup no matter how long it gets, so a thousand rows costs the same as ten. It is also the only version of this you can hand to somebody else to maintain.

Nearly always one of three things:

• The site redirects to a name it also answers to. Sending example.com to https://example.com is a loop unless something else changes on the way through.
• Redirect http to https is on and the backend also redirects to https, but the backend cannot tell the request already arrived on https. Check the pool has What is on the other end set correctly, so the backend is told the original scheme.
• Two sites both claim the same name and each sends to the other. The Sites list shows every name, so search it for the one that repeats.

The browser network tab shows the chain, and it usually names the culprit in the first two hops.

The application thinks it lives somewhere else, usually because it is on port 8080 behind the scenes and it puts that in the Location header. The visitor gets bounced to a port that is not open to them.

Open the site, Settings tab, Proxy, and use Rewrite redirect locations. Give it what the backend says and what it should say instead. That fixes it at the load balancer, which beats waiting for somebody to change the application.

If the backend sits under a path, Backend lives under this path in the same section handles the same problem for the path part.

Same cause as the redirect one above. The application sets a cookie for /app because that is where it thinks it lives, and the browser then refuses to send that cookie back for the address people actually use.

Open the site, Settings tab, Proxy, Rewrite cookie paths. Say what the backend sends and what it should be. Sign in stops silently failing.