2 x Applications using the same domain behind a reverse proxy

[Mik J]

Hello,
I don't manage to make my thing works although it's probably a classic for Nginx users.
I have a domain https://example.org
What I want is thishttps://example.org goes on reverse proxy => server1 (10.10.10.10) to the application /var/www/htdocs/app1https://example.org/app2 goes on reverse proxy => server1 (10.10.10.10) to the application /var/www/htdocs/app2 
So in the latter case the user adds /app2 and the flow is redirected to the /var/www/htdocs/app2 directory
First the reverse proxy, I wrote this    ##
    # App1    ##
     location / {
        proxy_pass              http://10.10.10.10:80;        proxy_redirect          off;
        proxy_set_header        Host                    $http_host;
        proxy_set_header        X-Real-IP               $remote_addr;
        proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;
        proxy_set_header        Referer                 "http://example.org";        #proxy_set_header       Upgrade                 $http_upgrade;
        #proxy_pass_header      Set-Cookie;
     }
    ##
    # App2    ##
     location /app2 {
        proxy_pass              http://10.10.10.10:80;        proxy_redirect          off;
        proxy_set_header        Host                    $http_host;
        proxy_set_header        X-Real-IP               $remote_addr;
        proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;
        proxy_set_header        Referer                 "http://example.org";        #proxy_set_header       Upgrade                 $http_upgrade;
        #proxy_pass_header      Set-Cookie;
     }


Second the back end serverserver {
        listen 80;
        server_name example.org;        index index.html index.php;
        root /var/www/htdocs/app1;

        access_log /var/log/nginx/example.org.access.log;        error_log /var/log/nginx/example.org.error.log;
        location / {
          try_files $uri $uri/ /index.php$is_args$args;
          location ~ \.php$ {
              root              /var/www/htdocs/app1;
              fastcgi_pass      unix:/run/php-fpm.app1.sock;              fastcgi_read_timeout 700;
              fastcgi_split_path_info ^(.+\.php)(/.+)$;
              fastcgi_index     index.php;
              fastcgi_param     SCRIPT_FILENAME $document_root$fastcgi_script_name;
              include           fastcgi_params;
          }
        }

         location /app2 {
          try_files $uri $uri/ /index.php$is_args$args;
          location ~ \.php$ {
              root              /var/www/htdocs/app2;
              fastcgi_pass      unix:/run/php-fpm.app1.sock;              fastcgi_read_timeout 700;
              fastcgi_split_path_info ^(.+\.php)(/.+)$;
              fastcgi_index     index.php;
              fastcgi_param     SCRIPT_FILENAME $document_root$fastcgi_script_name;
              include           fastcgi_params;
          }
        }}
The result I have right now is that I can access app1 with http://example.org, but i cannot access app2 with http://example.org/app2
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 ?
- can I mutualise the location ~ \.php$ between the two ?
- Should I copy access_log and error_log in the location /app2 statement ?

By the way, app1 and app2 are the same application/program but sometimes I want another instance or test app version 1, app version 2 etc.
What I tend to do in the past is to haveapp1.example.orgapp2.example.orgThe problem is that it makes me use multiple certificates.Here I want to group all the applications behind one domain name example.org with one certificate and then access different applications with example.org/app1, example.org/app2
Thank you






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20220717/0f4fd479/attachment.htm>