linux系统如何绑定域名,Linux 系统 Nginx如何绑定域名

Server 名称使用 “server_name” 指令来定义，并决定用哪一个 server 区块来处理请求. 另见

“Nginx如何处理请求”. 既可以用真实域名，也可以用通配符或正则表达式:

server {

listen 80;

server_name nginx.org www.nginx.org;

...

}

server {

listen 80;

server_name *.nginx.org;

...

}

server {

listen 80;

server_name mail.*;

...

}

server {

listen 80;

server_name

~^(?.+)\.nginx\.net$;

...

}

复制代码

域名已下面的顺序搜索:

真实域名;

以*开头的通配符: *.nginx.org;

以*结束的通配符名称: mail.*;

正则表达式.

第一个匹配的关键字将使搜索停止.

通配符名称

一个通配符名称只可以在域名的开头和结尾包含*, 而且只以'.'为边界. 域名 “www.*.nginx.org” and

“w*.nginx.org” 都是无效的. 但是，这些域名可以可以使用证则表达式来表示, 比如,

“~^www\..+\.nginx\.org$” 和 “~^w.*\.nginx\.org$”. * 可以匹配域名的很多部分.

“*.nginx.org” 不仅匹配

www.nginx.org

也匹配

www.sub.nginx.org

.

一个 “.nginx.org” 特殊形式的统配符域名可以同时被用来匹配 “nginx.org” 和

“*.nginx.org”.

正则表达式名称

Nginx使用的正则表达式和Perl兼容(PCRE). 使用证则表式的时候, server 名城必须以 '~' 开头:

server_name ~^www\d+\.nginx\.net$;

复制代码

不然的话它会被 当作一个真实域名来处理, 或者如果一个表达式包含 * , 那么回被当作统配符名称 . 不要忘记放 “^”和

“$”标记. 他们在语法上并不是必需的，但是逻辑上应该放. 同样注意域名中的'.'

应该用加转义符'\'. 一个包含“{” 和“}”

的正则表达式正则表达式应该用引号包含:

server_name "~^(?\w\d{1,3}+)\.nginx\.net$";

复制代码

否则

nginx 无法正常工作，并会显示错误信息:

directive "server_name" is not terminated by ";" in ...

复制代码

一个域名正则表达式可以使用单词作为变量:

server { server_name

~^(www\.)?(?.+)$; location /

{  root

/sites/$domain; }}

复制代码

PCRE 库支持使用以下形式表示变量:

?

Perl 5.10 兼容形式, PCRE-7.0以上支持

?'name'

Perl 5.10 兼容形式, PCRE-7.0以上支持

?P

Python 兼容形式,

PCRE-4.0以上支持

如果nginx启动失败，并显示错误信息:

pcre_compile() failed: unrecognized character after

(?< in ...

复制代码

这表示PCRE 库太旧了，你因该尝试

“?P”的形式.

也可以用点形势表示:

server { server_name ~^(www\.)?(.+)$; location / {

root

/sites/$2; }}

复制代码

然而这种方法只能在简单的例子上，就像上面这个例子.

多种域名

如果 “server_name” 没有被定义, 那么nginx 会把服务器名称当做 server name.

如果你想用非默认的 “Host” 头来处理请求, 你应该指定一个空域名:

server {

listen

80;

server_name nginx.org www.nginx.org "";

...

}

复制代码

如果想用 IP 而不是域名来处理请求, 那么 “Host” 头会包含对应的IP, 用来作为 server name:

server { listen  80; server_name nginx.org

www.nginx.org

""

192.168.1.1

;

...}

纵观所有的 server 案例，你会看到一个奇怪的 server name “_”:

server { listen  80 default_server;

server_name _; return

444;}

这个

name 其实没有什么特的, 它只是众多无效域名中的一个.

你也会看到像 “--”, “!@#”这样的 name.用来丢弃那些无效的请求.

nginx 从 0.6.25 开始支持特殊 name “*”, 它常被错误地解读为一个包含所有 name 的 name.

其实它从来都不是用来作为代表所有 name 的 name 或

统配符 name 来使用的. Instead, it supplied the

functionality that is now provided by the

“server_name_in_redirect” directive. The special name “*” is now

deprecated and the “server_name_in_redirect” directive should be

used. Note that there is no way to specify the catch-all name or

the

default

server using the “server_name” directive. This is a property of

the “listen” directive and not of the “server_name” directive. See

also “

How nginx processes a request

”. You can define servers listening on ports *:80 and *:8080,

and direct that one will be the default server for port *:8080,

while the other will be the default for port *:80:

server { listen  80; listen  8080 default_server;

server_name nginx.net;

...}server { listen  80 default_server; listen

8080;

server_name nginx.org;

...}

Optimization

Exact names and wildcard names are stored in hashes. The hashes

are bound to the listen ports and every listen port may have up to

three hashes: an exact names hash, a wildcard names hash starting

with an asterisk, and a wildcard names hash ending with an

asterisk. The sizes of the hashes are optimized at the

configuration phase so that a name can be found with the fewest CPU

cache misses. The exact names hash is searched first. If a name is

not found using the exact name hash, then the wildcard names hash

starting with an asterisk is searched. If the name is not found

there, the wildcard names hash ending with an asterisk is searched.

Searching wildcard names hashes is slower than searching exact name

hash because names are searched by domain parts. Note that the

special wildcard form “.nginx.org” is stored in a wildcard names

hash and not in an exact names hash. Regular expressions are tested

sequentially and therefore are the slowest method and are

non-scalable.

For these reasons, it is better to use exact names where

possible. For ex

amp

le, if the most frequently requested names of a server are

nginx.org

and

www.nginx.org

, it is more efficient to define them explicitly:

server { listen  80; server_name nginx.org www.nginx.org *.nginx.org; ...}

than to use the simplified form:

server { listen  80; server_name .nginx.org;

...}

If you have defined a large number of server names, or defined

unusually long server names, you may need to tune the

“server_names_hash_max_size” and “server_names_hash_bucket_size”

directives at the

http

level. The default value of the “server_names_hash_bucket_size”

may be equal to 32, or 64, or another value, depending on your CPU

cache line size. If the default value is 32 and you define

“too.long.server.name.nginx.org” as a server name, then nginx will

fail to start and display the error message:

could not build the server_names_hash,you should

increase server_names_hash_bucket_size: 32

In

this case, you should set the directive value to the next power of

2:

http {

server_names_hash_bucket_size 64; ...

If

you have defined a large number of server names, you will get

another error message:

could not build the server_names_hash,you should

increase either server_names_hash_max_size: 512or

server_names_hash_bucket_size: 32

You should first try to set “server_names_hash_max_size” to a

number close to the number of server names. Only if this does not

help, or if nginx’s start time is unacceptably long, should you try

to increase “server_names_hash_bucket_size”.

If a server is the only server for a listen port, then nginx

will not test server names at all (and will not build the hashes

for the listen port). However, there is one exception. If a

“server_name” is a regular expression with captures, then nginx has

to execute the expression to get the captures. Compatibility

Named regular expression server name captures have been

supported since 0.8.25.

Regular expression server name captures have been supported

since 0.7.40.

An empty server name “” has been supported since 0.7.12.

A wildcard server name or regular expression has been supported

for use as the first server name since 0.6.25.

Regular expression server names have been supported since

0.6.7.

Wildcard form nginx.* has been supported since

0.6.0.

The special form .nginx.org has been supported since

0.3.18.

Wildcard form *.nginx.org has been supported since

0.1.13.

written by Igor Sysoev

edited by Brian Mercer