Nginx & Apache


I would just like to say congrats on added nginx into the mix, of this totally cool script,

I had been doing a lot of research about nginx and was looking to start using it very soon, and not that it is supported with this script, im a happy man,

But I would like to have this popular new style setup that i was being told about on my visit to Silicon Valley.

All of the function of apache mixed with the speed of nginx,
From my understanding, this is done by both webservers being active on the server, but nginx is the main webserver running on port 80 and apache running on local poet 8080.

so when nginx get a request it can handle like PHP or something, apache with take the request, process it then send it to nginx to output.

Now I understand that you guy have only just gotten on board with the whole nginx thing, but can I request some form of module or at least a custom script for this process?

I know I could get this done easy with a freelance programmer, but I guessed it would be best to see if you guys are willing to offer this of all the users, even if this is to be a non-free add-on.

Please let me know what you think, and once again well done, and keep doing what you do.


If you click in input format, you can learn about the different formatting options. For example Markdown is the default. Then you could make your posting more readable :slight_smile:

On Ubuntu, Im currently using Apache behind an Nginx Proxy which really works fine with one exception:

Apache waits on Port 8888 and only accepts connections from Nginx listens on Port 80 to the real world - servers static content, does load balancing and handles proxy requests to Apache listening on 8888.

The Problem is:

PHP Scripts executed by Apache experience that the server Port is 8888. Scripts like phpmyadmin or nusoap provide redirecting and use this port as part of the redirect url. The Problem is Port 8888 is not visible from the outside thus no connection can be established.

Do you know where the configuration went wrong or how i can force php to think it is working on a port 80 Apache server?

As I cannot pin down the problem I have no clue whether posting my configuration files would help. Maybe its just an option I forgot or stuff.

But i have found some helpful info, and i think it’s best i share it as i move along,

There are basically two main parts involved in the configuration, one relating to Apache and one relating to Nginx.

Note that while we have chosen to describe the process for Apache in particular, this method can be applied to any other HTTP server. The only point that differs is the exact configuration sections and directives that you will have to edit. Otherwise, the principle of reverse-proxy can be applied, regardless of the server software you are using.

Reconfiguring Apache

There are two main aspects of your Apache configuration that will need to be edited in order to allow both Apache and Nginx to work together at the same time. But let us first clarify where we are coming from, and what we are going towards.

Configuration overview

At this point, you probably have the following architecture set up on your server:
•A web server application running on port 80, such as Apache
•A dynamic server-side script processing application such as PHP, communicating with your web server via CGI, FastCGI, or as a server module

The new configuration that we are going towards will resemble the following:
•Nginx running on port 80
•Apache or another web server running on a different port, accepting requests coming from local sockets only
•The script processing application configuration will remain unchanged

As you can tell, only two main configuration changes will be applied to Apache as well as the other web server that you are running. Firstly, change the port number in order to avoid conflicts with Nginx, which will then be running as the frontend server. Secondly, (although this is optional) you may want to disallow requests coming from the outside and only allow requests forwarded by Nginx. Both configuration steps are detailed in the next sections.

Resetting the port number

Depending on how your web server was set up (manual build, automatic configuration from server panel managers such as cPanel, Plesk, and so on) you may find yourself with a lot of configuration files to edit. The main configuration file is often found in /etc/httpd/conf/ or /etc/apache2/, and there might be more depending on how your configuration is structured. Some server panel managers create extra configuration files for each virtual host.

There are three main elements you need to replace in your Apache configuration:
•The Listen directive is set to listen on port 80 by default. You will have to replace that port by another such as 8080. This directive is usually found in the main configuration file.
•You must make sure that the following configuration directive is present in the main configuration file: NameVirtualHost A.B.C.D:8080, where A.B.C.D is the IP address of the main network interface on which server communications go through.
•The port you just selected needs to be reported in all your virtual host configuration sections, as described below.

The virtual host sections must be transformed from the following template

ServerName ServerAlias […]
to the following:

ServerName ServerAlias […]
In this example, A.B.C.D is the IP address of the virtual host and is the virtual host’s name. The port must be edited on the first two lines.

Accepting local requests only

There are many ways you can restrict Apache to accept only local requests, denying access to the outside world. But first, why would you want to do that? As an extra layer positioned between the client and Apache, Nginx provides a certain comfort in terms of security. Visitors no longer have direct access to Apache, which decreases the potential risk regarding all security issues the web server may have. Globally, it’s not necessarily a bad idea to only allow access to your frontend server.

The first method consists of changing the listening network interface in the main configuration file. The Listen directive of Apache lets you specify a port, but also an IP address, although, by default, no IP address is selected resulting in communications coming from all interfaces. All you have to do is replace the Listen 8080 directive by Listen; Apache should then only listen on the local IP address. If you do not host Apache on the same server, you will need to specify the IP address of the network interface that can communicate with the server hosting Nginx.

The second alternative is to establish per-virtual-host restrictions:

ServerName ServerAlias […] Order deny,allow allow from allow from eny all
Using the allow and deny Apache directives, you are able to restrict the allowed IP addresses accessing your virtual hosts. This allows for a finer configuration, which can be useful in case some of your websites cannot be fully served by Nginx.

Once all your changes are done, don’t forget to reload the server to make sure the new configuration is applied, such as service httpd reload or /etc/init.d/ httpd reload.

Configuring Nginx

There are only a couple of simple steps to establish a working configuration of Nginx, although it can be tweaked more accurately as seen in the next section.

Enabling proxy options

The first step is to enable proxying of requests from your location blocks. Since the proxy_pass directive cannot be placed at the http or server level, you need to include it in every single place that you want to be forwarded. Usually, a location / { fallback block suffices since it encompasses all requests, except those that match location blocks containing a break statement.

Here is a simple example using a single static backend hosted on the same server:

server { server_name; root /home/; […] location / { proxy_pass; }}
In the following example, we make use of an Upstream block allowing us to specify multiple servers:

upstream apache { server; server; server weight=2; server backup;} server { server_name; root /home/; […] location / { proxy_pass http://apache; }}
So far, with such a configuration, all requests are proxied to the backend server; we are now going to separate the content into two categories:
•Dynamic files: Files that require processing before being sent to the client, such as PHP, Perl, and Ruby scripts, will be served by Apache
•Static files: All other content that does not require additional processing, such as images, CSS files, static HTML files, and media, will be served directly by Nginx

We thus have to separate the content somehow to be provided by either server.

Separating content

In order to establish this separation, we can simply use two different location blocks—one that will match the dynamic file extensions and another one encompassing all the other files. This example passes requests for .php files to the proxy:

server { server_name; root /home/; […] location ~* .php.$ { # Proxy all requests with an URI ending with .php* # (includes PHP, PHP3, PHP4, PHP5…) proxy_pass; } location / { # Your other options here for static content # for example cache control, alias… expires 30d; }}
This method, although simple, will cause trouble with websites using URL rewriting. Most Web 2.0 websites now use links that hide file extensions such as; some even replace file extensions with links resembling the following: strengthens.html.

When building a reverse-proxy configuration, you have two options:
•Port your Apache rewrite rules to Nginx (usually found in the .htaccess file at the root of the website), in order for Nginx to know the actual file extension of the request and proxy it to Apache correctly.
•If you do not wish to port your Apache rewrite rules, the default behavior shown by Nginx is to return 404 errors for such requests. However, you can alter this behavior in multiple ways, for example, by handling 404 requests with the error_page directive or by testing the existence of files before serving them. Both solutions are detailed below.

Here is an implementation of this mechanism, using the error_page directive :

server { server_name; root /home/; […] location / { # Your static files are served here expires 30d; […] # For 404 errors, submit the query to the @proxy # named location block error_page 404 @proxy; } location @proxy { proxy_pass; }}
Alternatively, making use of the if directive from the Rewrite module:

server { server_name; root /home/; […] location / { # If the requested file extension ends with .php, # forward the query to Apache if ($request_filename ~* .php.$) { break; # prevents further rewrites proxy_pass; } # If the requested file does not exist, # forward the query to Apache if (!-f $request_filename) { break; # prevents further rewrites proxy_pass; } # Your static files are served here expires 30d; }}
There is no real performance difference between both solutions, as they will transfer the same amount of requests to the backend server. You should work on porting your Apache rewrite rules to Nginx if you are looking to get optimal performance.


Thanks for all your input!

Virtualmin may, at some point, have built-in support the setup you’re describing.

In the meantime, the goal was to get solid support of purely Nginx, and the more complex setup of Nginx+Apache would be down the road a bit.

However, there are those who, like yourself, want to use Apache as a backend – with a frontend of either Nginx, or maybe a proxy such as Varnish or Apache Traffic Server.

It actually can work now, it just requires manual configuration to make that function. For example, there are a few folks here in the forums who explain how they got Varnish working on port 80, and Apache on an alternate port.

I haven’t yet tried such a setup myself, and I’m not sure what direction to steer you, but I did want to let you know that with some tweaking, that should work – and that there may be folks here in the forums who could lend you a hand.

However, we’ll look into your ideas for a future version of the Nginx plugin – thanks for your thoughts!



That sounds like music to my ears,
Do you guys have a donation system for module development? as I would be more than happy to donate funds for an official module so that the whole community can benefit, not just myself.