Nginx default conf

Hello, I’m already going gray from searching for this…
Where can I find the settings for the default Nginx configuration when creating a site?
I tried modifying the default files in /virtualmin-nginx/?xnavigation=1.

The answer to questions like this is always Server Templates.

1 Like

i dont see default conf nginx file in that template :confused: i only see php options
is possible edit default config with nano or other editor?

Huh, it’s hidden in an uncomfortable place for nginx. But, I believe you can do what you’re after in:

Server Templates->->Plugin options->Adding Nginx config directives

I found it by clicking the search icon in the Server Templates page and typing “nginx” (which is usually how I find the specific answer to questions like this, there a couple of search boxes and they usually work pretty well for finding specific options.

@Jamie I wonder if it’s possible to make nginx more of a first class citizen in this regard? it’s sort of obscure finding where to customize the nginx directives. I think this option does it, but it’s not entirely clear how and it’s tucked away in the unintuitively named “Plugin options”, and most users probably don’t know that nginx is a plugin and treated differently from core features.

2 Likes

Indeed, it’s quite unintuitive; it’s probably easier to edit it directly in the file, but which file is it? Or is there no such option?

That’s an excellent idea, we should be able to allow plugins to define their own template categories. I’ll look into this.

3 Likes

Any edit causes a “violation” of the structure; quite simply, the file is ugly. Additionally, are there no systems in place to check for duplicates?

server {
	server_name domain.com ;
	listen 123123213213;
	listen123121321312312;
	root /home/domain/public_html;
	index index.php index.htm index.html;
	access_log /var/log/virtualmin/domain.com_access_log;
	error_log /var/log/virtualmin/domain.com_error_log;
	location ~* "^.+\.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|webp|zip|swf|map|mjs)$" {
		add_header Access-Control-Allow-Origin *;
		expires max;
		access_log off;
	}
	location ~ /\.(ht|svn|git) {
		deny all;
	}
	location ^~ /.well-known/ {
		try_files $uri /;
		deny all;
	}
	fastcgi_param GATEWAY_INTERFACE CGI/1.1;
	fastcgi_param SERVER_SOFTWARE nginx;
	fastcgi_param QUERY_STRING $query_string;
	fastcgi_param REQUEST_METHOD $request_method;
	fastcgi_param CONTENT_TYPE $content_type;
	fastcgi_param CONTENT_LENGTH $content_length;
	fastcgi_param SCRIPT_FILENAME "/home/domain/public_html$fastcgi_script_name";
	fastcgi_param SCRIPT_NAME $fastcgi_script_name;
	fastcgi_param REQUEST_URI $request_uri;
	fastcgi_param DOCUMENT_URI $document_uri;
	fastcgi_param DOCUMENT_ROOT /home/domain/public_html;
	fastcgi_param SERVER_PROTOCOL $server_protocol;
	fastcgi_param REMOTE_ADDR $remote_addr;
	fastcgi_param REMOTE_PORT $remote_port;
	fastcgi_param SERVER_ADDR $server_addr;
	fastcgi_param SERVER_PORT $server_port;
	fastcgi_param SERVER_NAME $server_name;
	fastcgi_param PATH_INFO $fastcgi_path_info;
	fastcgi_param HTTPS $https;
	location ^~ /.well-known/ {
		try_files $uri /;
	}
	location ~ "\.php(/|$)" {

add with
Adding Nginx config directives - Listed below …

1 Like

treated differently (yes a bit like an afterthought compared to Apache and it doesn’t deserve that these days) but that is much the same everywhere

looking forward to any improvement (I, like many I suspect, never bothered even looking for a template)

1 Like

There’s still an issue where, after selecting PHP version 8.1 and making any changes (or updates), it automatically switches to the highest possible version on its own. :confused:

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.

Ok this has been implemented for inclusion in the next release.

2 Likes

Jamie, it’s great, but we should integrate it into the “Website for Domain” section rather than displaying it under a new separate “Nginx Website” section. Apache and Nginx installations should be aligned for a better user experience.

To clarify, I am referring to “Directives and settings for new websites” and “Extra directives for SSL websites.” As we display these for Apache systems, we should do the same for Nginx, rather than scattering them across different pages.

1 Like

Hmmm … that’s not a bad idea I suppose, since there are options already in that template section which apply to Nginx and Apache.

Ok I’ve re-worked the plugin template code so that Nginx options will appear on the “website for domain” page.

2 Likes

@Jamie, superb, thanks! One tweak though—could you move “Adding Nginx config directives” to the top of the “Website for domain” template page, so it aligns with Apache systems?

Not easily, no

I could fairly easily make it work within the theme.

No no, that would be the wrong place to do it for sure. The theme should never be doing these kinds of re-organizations of page layouts …

1 Like

Yes, absolutely, and I don’t disagree. But the question now is—do we risk confusing users with UI inconsistency, go with a less-than-ideal but simple code solution for consistency, or fix it properly with a more thorough code change?

At some point I can look into allowing plugins to add template options that are mixed in with “core” options, but for now the current solution is simple and works well enough.