Having trouble with Nginx configuration (App Service Basic B2 - Linux, Nginx, MySQL, PHP 8.2)

V1xIII 0 Reputation points
2024-06-10T19:03:10.3933333+00:00

I'm a server newbie and am struggling to fix 404 errors on my Azure app service site.

Using the default configuration, I was having issues with all file paths causing 404's (images, css, js, etc.), though I could load the pages themselves. Originally it was using relative paths, but I had no luck with any other variations either. All the URLs in the page source look correct.

I decided to start monkeying around with the Nginx config and only made things worse by accidentally overwriting my original default config. Now I still have the same issues, but also can't access any pages other than index. I have a startup command that copies the custom nginx.conf file to the usual location (/etc/nginx/sites-enabled/default).

Can anyone help sort out my config? Or at least provide the original default config that I lost? Here is my current nginx.conf:

server {
    proxy_cache cache;
    proxy_cache_valid 200 1s;
    listen 8080;
    listen [::]:8080;
    root /home/site/wwwroot/themes/tcgadvance.com;
    index  index.q index.php index.html index.htm;
    server_name tcgadvance.com www.tcgadvance.com;
    port_in_redirect off;

    location / {
        index  index.q index.php index.html index.htm hostingstart.html;
        try_files $uri $uri/ /index.php?$args;
    }

    # redirect server error pages to the static page /50x.html
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /html/;
    }

    # Disable .git directory
    location ~ /\.git {
        deny all;
        access_log off;
        log_not_found off;
    }

    # Add locations of phpmyadmin here.
    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(|/.*)$;
        fastcgi_pass 127.0.0.1:9000;
        include fastcgi_params;
        fastcgi_param HTTP_PROXY "";
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param QUERY_STRING $query_string;
        fastcgi_intercept_errors on;
        fastcgi_connect_timeout         300;
        fastcgi_send_timeout           3600;
        fastcgi_read_timeout           3600;
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;
        fastcgi_temp_file_write_size 256k;
    }
}
Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
8,933 questions
{count} votes

2 answers

Sort by: Most helpful
  1. ajkuma 28,036 Reputation points Microsoft Employee Moderator
    2024-06-20T06:33:05.83+00:00

    @V1xIII , Apologies for the delayed response here.

    I understand you have tried multiples steps to isolate the issue. Kindly try these steps to further isolate the issue. Sorry for the long post, just sharing essential pointers based on your scenario.

    --If you haven't done, override NGINX’s configuration by following this post (depending on the app framework) or if using frameworks that serve content out of a different directory, like Laravel - mod

    The .php file must be relative to where root is set. For example, root may be set to/home/site/wwwroot/public - this index.php file must be under this directory.

    --For .js files that may be apart of Front-Ends ( example using Vue, React, Angular, or others (being served as production builds to PHP - eg., Laravel and Yii, etc.) , ensure these are on the file system. If not, then the frontends for these may not be built during deployment. Kindly check if npm run build or yarn run build is expected to be ran or if the production build folder is set in a .gitignore.

    --HTTP 404’s can come back from NGINX if site root does not match where the application root is. This is defined in the default.conf file under sites-available with the root directive.

    A common theme is with frameworks again - such as Laravel and Yii - where the application is served out of /public/ or /web/ - which would equate to /home/site/wwwwroot/public or /home/site/wwwroot/web - whereas NGINX’s default root is /home/site/wwwroot.

    -nginx.conf: This lives under /etc/nginx/nginx.conf

    1. Copy /etc/nginx/conf.d/default.conf to /home/dev.
      copy of the file will exist as /home/dev/default.conf
    2. Edit the existing startup fie in /home/dev/startup.sh to include the following:
    echo "Copying custom default.conf over to /etc/nginx/conf.d/default.conf"
    
    cp /home/dev/default.conf /etc/nginx/conf.d/default
    nginx -s reload
    
    

    --For 404’s due to endpoints not mapped to controllers, kindly check the source code to ensure these endpoints actually exist in their codebase. This will also depend on the framework used.

    --If App Service Logging is enabled , but debug mode is not enabled - the logging may only just show this - and not anything like a error/callstack written to stdout/err:

    [ERROR] 127.0.0.1 - 10/Jun/2024:13:16:13 +0000 "GET /index.php"


    If the answer helped (pointed, you in the right direction) > please click Accept Answer - it will benefit community members to find the answers quickly. 

    0 comments No comments

  2. V1xIII 0 Reputation points
    2024-06-24T19:56:28.7266667+00:00

    Regarding the images/css/js issue, it was an nginx configuration issue as I had assumed. I had to add the following to my "default" nginx config:

        # Handle image, CSS, and JS folders separately     
    	location /images/ {
            alias /home/site/wwwroot/themes/mywebsite.com/images/;
            try_files $uri $uri/ =404;
        }
        location /css/ {
            alias /home/site/wwwroot/themes/mywebsite.com/css/;
            try_files $uri $uri/ =404;
        }
        location /js/ {
            alias /home/site/wwwroot/themes/mywebsite.com/js/;         
    		try_files $uri $uri/ =404;
        }
    

    As for the problem that I caused (not being able to see other pages), I ultimately fixed by rolling back to a previous backup, though I'm not sure what was the exact culprit there.


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.