Test to ensure consistency of NGINX routes

We are migrating from a monolithic site to a fairly standard front-end/back-end architecture, and we're doing it piecemeal. As such we have quite complicated routing in our NGINX conf. When we migrate a new service from old system to new, we need to redirect the route, but given we have thousands of generated urls this is not always easy to reason about.

Let's use rooms and landing-pages as an example (but we have many conflicts like this)

nginx-frontend.conf

  # landing pages - to (eg) match /meeting-rooms/paris-2e-arrondissment
  location ~* "^/([\p{L}\p{N}-]+)/([\p{L}\p{L}-]+)/?$" {
    proxy_pass http://new:3000;
  }

  # rooms - to (eg) match /rooms/12345
    location ~* "^/rooms/([\p{N}]+)/?$" {
    proxy_pass http://old:3000;
  }

The eagle eyed of you will note that the first route (landing pages) also matches /rooms/12345 which is unintended and causes errors. We have similar problems with catching legacy css (/css/bobbins.js) and all sorts of other things.

The old and new services then perform their own routing internally to generate the correct data. We have all sorts of even more legacy routes on the old server which makes turning its corresponding routes off equally dangerous/frustrating.

What I would like to do is have a list of routes with the expected service written as some sort of test (don't care which language - python, node.js or php are preferable, but I'll adopt a new one if necessary to fix this) along these lines (pseudocode)

[
  { 
     test: ['/rooms/12345/', '/rooms/12346', ...],
     expect: service.to.be(old)
  },
  {
     test: ['/meeting-rooms/paris-2e-arrondissment/', '/meeting-rooms/london', ...],
     expect: service.to.be(new)
  }
]

Then, when we change a route, we can be certain that we have not accidentally introduced a problem

We're using docker, and I'm aware I will probably have to build a complete solution rather than expecting a quick line of code.

Is there a standard way of achieving this, or a service that I can employ? If not, outlines for potential solutions will also be gratefully received.