If you're using AWS, an alternative approach is to use an Application Load Balancer (ALB) to proxy for you. This way, any updates/configuration changes you make on the instance won't affect this; you are decoupling the proxy from the server OS. This should alleviate OP's concern in his comment under Karl DeBisschop's comment.
Full documentation here, but an overview is:
Configure an ALB. This will include configuring your "Listeners", which will "listen" for traffic destined to port 80 from the outside (e.g. clients), and it will include configuring your "Target Group", which will "listen" for traffic destined to port 4440 from your ALB's Listener.
The flow is: Client requests 80 -> Listener receives request -> Listener "forwards" request to Target Group -> EC2 instance receives on port 4440
--
Note that you must register EC2 to the Target Group manually, or via the auto scaling group configuration. If after registering you get a 302 health check error, this just means your health check path is wrong. A quick way to correct this is to do...
curl -vL <your URL destination>
The output should show both your 302 redirect as well as the 200 response (assuming your web app is running OK). Find the path under the 302 redirect response, and paste that into the Target Group health check path:
> GET / HTTP/1.1
> Host: XXXXXXXXX.us-east-1.elb.amazonaws.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Wed, 11 Mar 2020 18:19:57 GMT
< Content-Length: 0
< Connection: keep-alive
< Set-Cookie: JSESSIONID=XXXXXXXXXX; Path=/; HttpOnly
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Location: http://XXXXXXXXX.us-east-1.elb.amazonaws.com/user/login
<
* Connection #0 to host XXXXXXXXX.us-east-1.elb.amazonaws.com left intact
* Issue another request to this URL: 'http://XXXXXXXXX.us-east-1.elb.amazonaws.com/user/login'
[omitted]
* Connected to XXXXXXXXX.us-east-1.elb.amazonaws.com (10.1.1.1) port 80 (#0)
> GET /user/login HTTP/1.1 <-------------- this path is what you want