Yes, you can certainly front your server with another that is more capable. This is common-practice in enterprise environments, particularly when you have deployments on lagacy platforms.
The terminology you're looking for is called 'reverse-proxying', and its not something you get without repurcussions.
You'll need to know the following:
- Knowledge about HTTP, particularly about request headers such as Host and X-Forwarded-For etc.
- Understanding how the traffic flow will change (the originating server would start seeing traffic from the reverse-proxy)
- How to configure your originating server/application to work currectly behind a reverse-proxy. This would include a) access logging; b) correct forumulation of links, if the application were to create self-referring links to itself; c) any IP-related access-control decisions made by the application.
In theory, setting up a reverse-proxy is not difficult... but it is often done poorly when you don't tend to your plumbing, and you can end up with operational issues such as redirection loops as well as security / auditability issues.
You likely have this on a single-server already (otherwise you'd likely already have a reverse-proxy); so serious consideration should be given to just replatforming the appplication onto a supported platform; particularly if you're new to reverse-proxying.
Reverse-proxying does have other benefits though:
- The ability to filter traffic before it gets to your originating server;
- The ability to have static assets served by a capable web-server; reducing load on your originating server;
- The ability to cache traffic; reducing load on your originating server;
- The ability to inject other intermediaries, such as Web Application Firewalls (WAF), Content Delivery Networks (CDN)s, authentication (eg. SSO, MFA) etc.
Good luck, and good testing!
