On Tue, Jul 26, 2022 at 01:11:45AM +0000, Mik J via nginx wrote: Hi there,
I don't have a full answer, but a few config changes should hopefully help with the ongoing diagnosis. > When I access to example.org, I was to use /var/www/htdocs/app1 and it works. > > When I access to example.org/app2, I was to use /var/www/htdocs/app2 and it > doesn't really work. > location / { > try_files $uri $uri/ /index.php$is_args$args; > root /var/www/htdocs/app1; That says "a request for /thing will look for the file /var/www/htdocs/app1/thing, or else will become a subrequest for /index.php". So far, so good. > location /app2 { > #root /var/www/htdocs/app2; > alias /var/www/htdocs/app2; > try_files $uri $uri/ /index.php$is_args$args; Depending on whether you use "root" or "alias" there, a request for "/app2/thing" will look for one of two different files, or else become a subrequest for "/index.php". I suspect that instead of the above, you want root /var/www/htdocs; try_files $uri $uri/ /app2/index.php$is_args$args; so that if /var/www/htdocs/app2/thing does not exist, the subrequest is for /app2/index.php. > location ~ \.php$ { > root /var/www/htdocs/app2; With that, later things will be looking for /var/www/htdocs/app2/app2/index.php (double /app2) which almost certainly does not exist. With "root" set correctly outside this location{}, you can remove that "root" line entirely. Or change it to be "root /var/www/htdocs;". Those two changes to within "location /app2" and the nested "location ~ \.php$" should be enough to allow whatever the next error is, to appear. If you test by doing (for example) curl -i http://example.org/app2/ the response http headers and content may give a clue as to what is happening versus what should be happening. For the other problem reports -- if they matter, if you can include enough of the configuration that it can be copy-paste'd in to a test system, it will be simpler for someone else to repeat what you are doing. But possibly the above change will mean that they no longer happen. You had a few other questions initially: > > Also what is the best practice on the backend server: > > - should I make one single virtual host with two location statements > > like I did or 2 virtual hosts with a fake name like > > internal.app1.example.org and internal.app2.example.org ? The answer there is always "it depends" :-( In this case, you have moved away from proxy_pass to a backend server, towards fastcgi_pass to a local socket; so I guess it doe not really matter here and now. The more important thing is: does your application allow itself to be (reverse-proxy) accessed or installed in a "subdirectory" like "/app2/"? If it does not, then there are likely to be problems. > > - can I mutualise the location ~ \.php$ between the two ? Probably not; because the two location{}s probably have different requirements. You might be able to have all of the fastcgi_param directives in a common place, and "just" have duplicate "fastcgi_pass" directives in the two locations, though. > > - Should I copy access_log and error_log in the location /app2 statement ? As you wish. You can have nginx writing one log file, and make sure that whatever is reading it knows how to interpret it; or you can have nginx writing multiple log files, and have whatever is reading each one, know how to interpret that one. I suspect that the main advantage to "different log files per location" is that it will be very clear which location{} was in use when the request completed; and if that is not the one that you expected, then you'll want to investigate why. (The main disadvantage is: multiple files to search through, in case things were not handled as you expected.) Good luck with it, f -- Francis Daly fran...@daoine.org _______________________________________________ nginx mailing list -- nginx@nginx.org To unsubscribe send an email to nginx-le...@nginx.org