Directive can have multiple meanings. Each variant is separated with horizontal line


[edit] server

Syntax: server { ... }
Default:
Context: http
Reference: server


Directive assigns configuration for the virtual server.

There is no separation of IP and name-based (the Host header of the request) servers.

Instead, the directive listen is used to describe all addresses and ports on which incoming connections can occur, and in directive server_name indicate all names of the server.


Module: HttpCoreModule

[edit] server

Syntax: server address [ parameters ]
Default:
Context: upstream
Reference: server


Directive assigns the name and the parameters of server. For the name it is possible to use a domain name, an address, port or unix socket. If domain name resolves to several addresses, then all are used.

Example configuration:

upstream  backend  {
  server   backend1.example.com    weight=5;
  server   127.0.0.1:8080          max_fails=3  fail_timeout=30s;
  server   unix:/tmp/backend3;
}

Attention: If you use only one upstream server nginx set a internal variable to 1, this means that the max_fails & fail_timeout parameter are not handled.

Effect: If nginx can not connect to upstream the request it's gone.

Solution: Use the same server several times


Module: HttpUpstreamModule

[edit] server

syntax: server {...}

default: no

context: mail

Directive assigns configuration for the virtual server.

There is no clear separation of the virtual servers ip-based and name-based (the value of the line "Host" header in the request).

Instead of this by directives listen are described all addresses and ports, on which it is necessary to assume connections for this server, and in directive server_name are indicated all names of servers. Example configurations are described in tuning of virtual servers.


Module: MailCoreModule