I am currently trying to determine how to appropriately set passenger_base_uri when running passenger in standalone mode. I tried overriding the nginx.conf.erb to include passenger_base_uri, I also tried setting the location block as specified on https://www.phusionpassenger.com/library/deploy/nginx/deploy/ruby/#deploying-an-app-to-a-sub-uri Both of those methods produced the strange result of randomly serving 404s.
Was curious if there was a straightforward way to configure this for a single app (it looks like there might have been a environment variable option to allow this at some point?).
I'm not trying to deploy multiple apps on a single passenger server, just trying to change the context of a single app without having to alter routes.
Versions from passenger-status: nginx/1.12.2 Phusion_Passenger/5.2.3
Update: I tried on the latest version of passenger (6.0.1) and still see random 404s. I also tried upping the logging level on passenger and it appears that there is an issue where some of the passenger processes aren't appropriately setting "SCRIPT_NAME" before passing the request through. I can't seem to reproduce this error locally, but can reliably reproduce it in a deployed instance.
Same pid serving both 404s and 200s:
# passenger-status && curl -I -k https://127.0.0.1/test/meta/availability
Version : 6.0.1
Date : 2019-01-23 00:31:59 +0000
Instance: 36X3YTqe (nginx/1.15.8 Phusion_Passenger/6.0.1)
----------- General information -----------
Max pool size : 10
App groups : 1
Processes : 10
Requests in top-level queue : 0
----------- Application groups -----------
/opt/app (production):
App root: /opt/app
Requests in queue: 0
* PID: 129 Sessions: 0 Processed: 59 Uptime: 12m 55s
CPU: 0% Memory : 68M Last used: 1s ago
* PID: 152 Sessions: 0 Processed: 1 Uptime: 12m 54s
CPU: 0% Memory : 45M Last used: 12m 54s ago
* PID: 176 Sessions: 0 Processed: 0 Uptime: 12m 54s
CPU: 0% Memory : 41M Last used: 12m 54s ago
* PID: 202 Sessions: 0 Processed: 0 Uptime: 12m 53s
CPU: 0% Memory : 41M Last used: 12m 53s ago
....
HTTP/1.1 200 OK
Date: Wed, 23 Jan 2019 00:32:00 GMT
X-Powered-By: Phusion Passenger 6.0.1
Server: nginx/1.15.8 + Phusion Passenger 6.0.1
# passenger-status && curl -I -k https://127.0.0.1/test/meta/availability
Version : 6.0.1
Date : 2019-01-23 00:32:01 +0000
Instance: 36X3YTqe (nginx/1.15.8 Phusion_Passenger/6.0.1)
----------- General information -----------
Max pool size : 10
App groups : 1
Processes : 10
Requests in top-level queue : 0
----------- Application groups -----------
/opt/app (production):
App root: /opt/app
Requests in queue: 0
* PID: 129 Sessions: 0 Processed: 60 Uptime: 12m 57s
CPU: 0% Memory : 68M Last used: 1s ago
* PID: 152 Sessions: 0 Processed: 1 Uptime: 12m 56s
CPU: 0% Memory : 45M Last used: 12m 56s ago
* PID: 176 Sessions: 0 Processed: 0 Uptime: 12m 56s
CPU: 0% Memory : 41M Last used: 12m 56s ago
* PID: 202 Sessions: 0 Processed: 0 Uptime: 12m 55s
CPU: 0% Memory : 41M Last used: 12m 55s ago
....
HTTP/1.1 404 Not Found
Date: Wed, 23 Jan 2019 00:32:01 GMT
X-Powered-By: Phusion Passenger 6.0.1
Server: nginx/1.15.8 + Phusion Passenger 6.0.1
Got some feedback on a similar sounding github issue. Looks to be an issue with newer versions of passenger (greater than 5.1, current highest available is 6.0.1). It should be possible to just set passenger_base_uri, but the bug causes the random 404s.