Nginx服务器中location配置的一些基本要点解析

在这一篇文章里,我将介绍nginx关于location的处理,大家都知道Nginx配置文件里面会有很多的location,nginx的配置指令的作用域可以分为 main,server,location这3个种,实际上这3者不是依次包含的关系,而是相互独立的关系,比如一个只具有main级别作用域的指令,是不能写在某个server或者location内的,模块的某个指令可以同时具有main,server,location这3种作用域,另外每个模块有 main,srv,loc这3个级别的配置,一个模块的main级别的配置对所有的server和location都是共享的,srv级别的配置对所有 location都是共享的,location只有自己独立的loc级别的配置,这就是为什么一个模块的srv和loc级别的配置需要merge,而 main级别的配置不需要merge的原因。这里看起来有点绕,区分一下main,server,location分别作为一种作用域级别和一个主体,类似于形容词和名字的区别,nginx的配置关系还是不难理解的。

一般来说一个请求url过来,nginx会将它解析到某一个location来处理。这个解析的过程实际上根据location的配置基本可以分为字符串匹配和正则表达式匹配这2种。对于location的组织方式,最简单的就是直接将它们保存为一个链表,解析url的时候一个一个遍历即可找到相应location,但是这样效率太低,对像nginx这种高性能的服务器来说是完全不可取的,nginx将字符串匹配的location组织成了一个三叉的字符串排序树,而且建立的时候也考虑了树的平衡性。文章后面我讲详细介绍源码的实现。

首先我来大概的介绍一下location的种类和匹配规则,以nginx wiki(http://wiki.nginx.org/HttpCoreModule#location)的例子做说明:

location = / {
 # matches the query / only.
 [ configuration A ]
}
location / {
 # matches any query, since all queries begin with /, but regular
 # expressions and any longer conventional blocks will be
 # matched first.
 [ configuration B ]
}
location ^~ /images/ {
 # matches any query beginning with /images/ and halts searching,
 # so regular expressions will not be checked.
 [ configuration C ]
}
location ~* \.(gif|jpg|jpeg)$ {
 # matches any request ending in gif, jpg, or jpeg. However, all
 # requests to the /images/ directory will be handled by
 # Configuration C.
 [ configuration D ]
} 

location @named {
 # Such locations are not used during normal processing of requests,
 # they are intended only to process internally redirected requests (for example error_page, try_files).
 [ configuration E ]
}

可以看到上面的例子中有5种不同类型的location,其中第4个带 “~” 号前缀的为需要正则匹配的location,nginx在进行url解析时对这5种不同类型的location具有不同的优先级规则,大致的规则如下:

1,字符串精确匹配到一个带 “=” 号前缀的location,则停止,且使用这个location的配置;

2,字符串匹配剩下的非正则和非特殊location,如果匹配到某个带 "^~" 前缀的location,则停止;

3,正则匹配,匹配顺序为location在配置文件中出现的顺序。如果匹配到某个正则location,则停止,并使用这个location的配置;否则,使用步骤2中得到的具有最大字符串匹配的location配置。

例如,对下面的请求有:

1, /   ->   精确匹配到第1个location,匹配停止,使用configuration A
2,/some/other/url    ->  首先前缀部分字符串匹配到了第2个location,然后进行正则匹配,显然没有匹配上,则使用第2个location的配置configurationB
3,/images /1.jpg  ->  首先前缀部分字符串匹配到了第2个location,但是接着对第3个location也前缀匹配上了,而且这时已经是配置文件里面对这个url的最大字符串匹配了,并且location带有 "^~" 前缀,则不再进行正则匹配,最终使用configuration C
4,/some/other/path/to/1.jpg  -> 首先前缀部分同样字符串匹配到了第2个location,然后进行正则匹配,这时正则匹配成功,则使用congifuration D

nginx的url匹配规则实际上有点不妥,大部分情况下一个url必须先进行字符串匹配,然后再做正则匹配,但是实际上如果先做正则匹配,没有匹配上再 做字符串匹配,在很多情况下可以节省掉做字符串匹配的时间。不管怎样,先来看一下nginx源码里面的实现,在介绍匹配location过程之前,先来介 绍一下nginx里面对location的组织方式,实际上在配置解析阶段,nginx将字符串匹配的location和正则匹配的location分别 存储在http core模块的loc配置ngx_http_core_loc_conf_t结构的下面2个字段:

ngx_http_location_tree_node_t  *static_locations;
(NGX_PCRE)
ngx_http_core_loc_conf_t    **regex_locations;
if

从这2个字段的类型可以看出,字符串匹配的location被组织成了一个location tree,而正则匹配的location只是一个数组,

location tree和regex_locations数组建立过程在ngx_http_block中:
/* create location trees */ 

  for (s = 0; s < cmcf->servers.nelts; s++) { 

    clcf = cscfp[s]->ctx->loc_conf[ngx_http_core_module.ctx_index]; 

    if (ngx_http_init_locations(cf, cscfp[s], clcf) != NGX_OK) {
      return NGX_CONF_ERROR;
    } 

    if (ngx_http_init_static_location_trees(cf, clcf) != NGX_OK) {
      return NGX_CONF_ERROR;
    }
  }

经过配置的读取之后,所有server都被保存在http core模块的main配置中的servers数组中,而每个server里面的location都被按配置中出现的顺序保存在http core模块的loc配置的locations队列中,上面的代码中先对每个server的location进行排序和分类处理,这一步发生在 ngx_http_init_location()函数中:

static ngx_int_t
ngx_http_init_locations(ngx_conf_t *cf, ngx_http_core_srv_conf_t *cscf,
  ngx_http_core_loc_conf_t *pclcf)
{
 ...
  locations = pclcf->locations; 

 ...
  /* 按照类型排序location,排序完后的队列: (exact_match 或 inclusive) (排序好的,如果某个exact_match名字和inclusive location相同,exact_match排在前面)
    | regex(未排序)| named(排序好的) | noname(未排序)*/
  ngx_queue_sort(locations, ngx_http_cmp_locations); 

  named = NULL;
  n = 0;
#if (NGX_PCRE)
  regex = NULL;
  r = 0;
#endif 

  for (q = ngx_queue_head(locations);
     q != ngx_queue_sentinel(locations);
     q = ngx_queue_next(q))
  {
    lq = (ngx_http_location_queue_t *) q; 

    clcf = lq->exact ? lq->exact : lq->inclusive;
    /* 由于可能存在nested location,也就是location里面嵌套的location,这里需要递归的处理一下当前location下面的nested location */
    if (ngx_http_init_locations(cf, NULL, clcf) != NGX_OK) {
      return NGX_ERROR;
    } 

#if (NGX_PCRE) 

    if (clcf->regex) {
      r++; 

      if (regex == NULL) {
        regex = q;
      } 

      continue;
    } 

#endif 

    if (clcf->named) {
      n++; 

      if (named == NULL) {
        named = q;
      } 

      continue;
    } 

    if (clcf->noname) {
      break;
    }
  } 

  if (q != ngx_queue_sentinel(locations)) {
    ngx_queue_split(locations, q, &tail);
  }
  /* 如果有named location,将它们保存在所属server的named_locations数组中 */
  if (named) {
    clcfp = ngx_palloc(cf->pool,
              (n + 1) * sizeof(ngx_http_core_loc_conf_t **));
    if (clcfp == NULL) {
      return NGX_ERROR;
    } 

    cscf->named_locations = clcfp; 

    for (q = named;
       q != ngx_queue_sentinel(locations);
       q = ngx_queue_next(q))
    {
      lq = (ngx_http_location_queue_t *) q; 

      *(clcfp++) = lq->exact;
    } 

    *clcfp = NULL; 

    ngx_queue_split(locations, named, &tail);
  } 

#if (NGX_PCRE)
  /* 如果有正则匹配location,将它们保存在所属server的http core模块的loc配置的regex_locations 数组中,
    这里和named location保存位置不同的原因是由于named location只能存在server里面,而regex location可以作为nested location */
  if (regex) { 

    clcfp = ngx_palloc(cf->pool,
              (r + 1) * sizeof(ngx_http_core_loc_conf_t **));
    if (clcfp == NULL) {
      return NGX_ERROR;
    } 

    pclcf->regex_locations = clcfp; 

    for (q = regex;
       q != ngx_queue_sentinel(locations);
       q = ngx_queue_next(q))
    {
      lq = (ngx_http_location_queue_t *) q; 

      *(clcfp++) = lq->exact;
    } 

    *clcfp = NULL; 

    ngx_queue_split(locations, regex, &tail);
  } 

#endif 

  return NGX_OK;
}

上面的步骤将正则匹配的location保存好了,location tree的建立在ngx_http_init_static_location_trees中进行:

static ngx_int_t
ngx_http_init_static_location_trees(ngx_conf_t *cf,
  ngx_http_core_loc_conf_t *pclcf)
{
  ngx_queue_t        *q, *locations;
  ngx_http_core_loc_conf_t  *clcf;
  ngx_http_location_queue_t *lq; 

  locations = pclcf->locations; 

  if (locations == NULL) {
    return NGX_OK;
  } 

  if (ngx_queue_empty(locations)) {
    return NGX_OK;
  }
  /* 这里也是由于nested location,需要递归一下 */
  for (q = ngx_queue_head(locations);
     q != ngx_queue_sentinel(locations);
     q = ngx_queue_next(q))
  {
    lq = (ngx_http_location_queue_t *) q; 

    clcf = lq->exact ? lq->exact : lq->inclusive; 

    if (ngx_http_init_static_location_trees(cf, clcf) != NGX_OK) {
      return NGX_ERROR;
    }
  }
  /* join队列中名字相同的inclusive和exact类型location,也就是如果某个exact_match的location名字和普通字符串匹配的location名字相同的话,
    就将它们合到一个节点中,分别保存在节点的exact和inclusive下,这一步的目的实际是去重,为后面的建立排序树做准备 */
  if (ngx_http_join_exact_locations(cf, locations) != NGX_OK) {
    return NGX_ERROR;
  }
  /* 递归每个location节点,得到当前节点的名字为其前缀的location的列表,保存在当前节点的list字段下 */
  ngx_http_create_locations_list(locations, ngx_queue_head(locations)); 

  /* 递归建立location三叉排序树 */
  pclcf->static_locations = ngx_http_create_locations_tree(cf, locations, 0);
  if (pclcf->static_locations == NULL) {
    return NGX_ERROR;
  } 

  return NGX_OK;
}

经过ngx_http_init_location()函数处理之后,locations队列已经是排好序的了,建立三叉树的过程的主要工作都在ngx_http_create_locations_list()和ngx_http_create_locations_tree()中完成,这2个 函数都是递归函数,第1个函数递归locations队列中的每个节点,得到以当前节点的名字为前缀的location,并保存在当前节点的list字段 下,例如,对下列location:

location /xyz { 

} 

location = /xyz { 

}
location /xyza { 

} 

location /xyzab { 

}
location /xyzb { 

}
location /abc { 

}
location /efg { 

}
location /efgaa { 

}

排序的结果为/abc  /efg   /efgaa  =/xyz  /xyz  /xyza /xyzab /xyzb,去重后结果为 /abc  /efg   /efgaa   /xyz  /xyza /xyzab/xyzb,ngx_http_create_locations_list()执行后的结果为:

最后,来看下ngx_http_create_locations_tree函数:

static ngx_http_location_tree_node_t *
ngx_http_create_locations_tree(ngx_conf_t *cf, ngx_queue_t *locations,
  size_t prefix)
{
  ...
  /* 根节点为locations队列的中间节点 */
  q = ngx_queue_middle(locations); 

  lq = (ngx_http_location_queue_t *) q;
  len = lq->name->len - prefix; 

  node = ngx_palloc(cf->pool,
           offsetof(ngx_http_location_tree_node_t, name) + len);
  if (node == NULL) {
    return NULL;
  } 

  node->left = NULL;
  node->right = NULL;
  node->tree = NULL;
  node->exact = lq->exact;
  node->inclusive = lq->inclusive; 

  node->auto_redirect = (u_char) ((lq->exact && lq->exact->auto_redirect)
              || (lq->inclusive && lq->inclusive->auto_redirect)); 

  node->len = (u_char) len;
  ngx_memcpy(node->name, &lq->name->data[prefix], len); 

  /* 从中间节点开始断开 */
  ngx_queue_split(locations, q, &tail); 

  if (ngx_queue_empty(locations)) {
    /*
     * ngx_queue_split() insures that if left part is empty,
     * then right one is empty too
     */
    goto inclusive;
  } 

  /* 从locations左半部分得到左子树 */
  node->left = ngx_http_create_locations_tree(cf, locations, prefix);
  if (node->left == NULL) {
    return NULL;
  } 

  ngx_queue_remove(q); 

  if (ngx_queue_empty(&tail)) {
    goto inclusive;
  } 

  /* 从locations右半部分得到右子树 */
  node->right = ngx_http_create_locations_tree(cf, &tail, prefix);
  if (node->right == NULL) {
    return NULL;
  } 

inclusive: 

  if (ngx_queue_empty(&lq->list)) {
    return node;
  } 

  /* 从list队列得到tree子树 */
  node->tree = ngx_http_create_locations_tree(cf, &lq->list, prefix + len);
  if (node->tree == NULL) {
    return NULL;
  } 

  return node;
}
     location tree节点的ngx_http_location_tree_node_s结构:
struct ngx_http_location_tree_node_s {
  ngx_http_location_tree_node_t  *left;
  ngx_http_location_tree_node_t  *right;
  ngx_http_location_tree_node_t  *tree; 

  ngx_http_core_loc_conf_t    *exact;
  ngx_http_core_loc_conf_t    *inclusive; 

  u_char              auto_redirect;
  u_char              len;
  u_char              name[1];
};

location tree结构用到的是left,right,tree 这3个字段, location tree实际上是一个三叉的字符串排序树,而且这里如果某个节点只考虑左,右子树,它是一颗平衡树,它的建立过程有点类似于一颗平衡排序二叉树的建立过程,先排序再用二分查找找到的节点顺序插入,ngx_http_location_tree_node_s的tree节点也是一颗平衡排序树,它是用该节点由ngx_http_create_locations_list()得到的list建立的,也就是该节点的名字是它的tree子树里面的所有节点名字的前缀,所以tree子树里面的所有节点的名字不用保存公共前缀,而且查找的时候,如果是转向tree节点的话,也是不需要再比较父节点的那段字符串了。
         ngx_http_create_locations_tree()函数写的很清晰,它有一个参数是队列locations,它返回一颗三叉树,根节点为locations的中间节点,其左子树为locations队列的左半部分建立的location tree,右子树为location队列的右半部分建立的tree,tree节点为该根节点的list队列建立的tree。

最终建立的location tree如下(为了方便阅读,图中列出了tree节点的完整名字):

PS:关于 location modifier
1. =
这会完全匹配指定的 pattern ,且这里的 pattern 被限制成简单的字符串,也就是说这里不能使用正则表达式。

Example:
server {
  server_name jb51.net;
  location = /abcd {
  […]
  }
}

匹配情况:

  http://jb51.net/abcd    # 正好完全匹配
  http://jb51.net/ABCD    # 如果运行 Nginx server 的系统本身对大小写不敏感,比如 Windows ,那么也匹配
  http://jb51.net/abcd?param1¶m2  # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1¶m2
  http://jb51.net/abcd/  # 不匹配,因为末尾存在反斜杠(trailing slash),Nginx 不认为这种情况是完全匹配
  http://jb51.net/abcde  # 不匹配,因为不是完全匹配

2. (None)
可以不写 location modifier ,Nginx 仍然能去匹配 pattern 。这种情况下,匹配那些以指定的 patern 开头的 URI,注意这里的 URI 只能是普通字符串,不能使用正则表达式。

Example:
server {
  server_name jb51.net;
  location /abcd {
  […]
  }
}

匹配情况:

  http://jb51.net/abcd    # 正好完全匹配
  http://jb51.net/ABCD    # 如果运行 Nginx server 的系统本身对大小写不敏感,比如 Windows ,那么也匹配
  http://jb51.net/abcd?param1¶m2  # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1¶m2
  http://jb51.net/abcd/  # 末尾存在反斜杠(trailing slash)也属于匹配范围内
  http://jb51.net/abcde  # 仍然匹配,因为 URI 是以 pattern 开头的

3. ~
这个 location modifier 对大小写敏感,且 pattern 须是正则表达式

Example:
server {
  server_name jb51.net;
  location ~ ^/abcd$ {
  […]
  }
}

匹配情况:

  http://jb51.net/abcd    # 完全匹配
  http://jb51.net/ABCD    # 不匹配,~ 对大小写是敏感的
  http://jb51.net/abcd?param1¶m2  # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1¶m2
  http://jb51.net/abcd/  # 不匹配,因为末尾存在反斜杠(trailing slash),并不匹配正则表达式 ^/abcd$
  http://jb51.net/abcde  # 不匹配正则表达式 ^/abcd$

注意:对于一些对大小写不敏感的系统,比如 Windows ,~ 和 ~* 都是不起作用的,这主要是操作系统的原因。

4. ~*
与 ~ 类似,但这个 location modifier 不区分大小写,pattern 须是正则表达式

Example:
server {
  server_name jb51.net;
  location ~* ^/abcd$ {
  […]
  }
}

匹配情况:

 http://jb51.net/abcd    # 完全匹配
  http://jb51.net/ABCD    # 匹配,这就是它不区分大小写的特性
  http://jb51.net/abcd?param1¶m2  # 忽略查询串参数(query string arguments),这里就是 /abcd 后面的 ?param1¶m2
  http://jb51.net/abcd/  # 不匹配,因为末尾存在反斜杠(trailing slash),并不匹配正则表达式 ^/abcd$
  http://jb51.net/abcde  # 不匹配正则表达式 ^/abcd$

5. ^~
匹配情况类似 2. (None) 的情况,以指定匹配模式开头的 URI 被匹配,不同的是,一旦匹配成功,那么 Nginx 就停止去寻找其他的 Location 块进行匹配了(与 Location 匹配顺序有关)

6. @
用于定义一个 Location 块,且该块不能被外部 Client 所访问,只能被 Nginx 内部配置指令所访问,比如 try_files or error_page

(0)

相关推荐

  • Nginx服务器初期基本配置指南

    一.准备 pcre,有关正则表达式匹配:zlib,用于压缩.这些就不细说了,如果要安装最简版的nginx,记得准备好这两样东西就好了. 用root账户启动服务是比较危险的!  前段时间,测试服务器被黑掉了,终归到底是通过一个root启动的服务上传了木马,最后连ssh都屏蔽了,活生生成为一台肉鸡... 所以,惨痛的经验告诉我,一定要为服务建立对应的组和用户,限制访问权限,降低风险!  这里为nginx建立一个www组,并建立一个不登录的账户nginx: #追加一个www组 groupadd -f

  • 使用referer指令配置Nginx服务器来防止图片盗链

    由于nginx不支持.htaccess,所以,从这个方面直接去防止是行不通的,我们要通过修改配置文件来解决. 首先,我们找到需要防盗链的域名的conf文件,路径:/usr/local/nginx/conf/vhost/,比如guance.com.conf.先备份下原文件,然后找到下面的部分: location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ { expires 30d; } 将它修改为: location ~ .*\.(gif|jpg|jpeg|png|bmp

  • Nginx的伪静态配置中使用rewrite来实现自动补全的实例

    nginx+php 使用的时候经常需要伪静态,一般大家都手动设置.那有没有办法让 nginx 自动补全路径呢? 这两天折腾很久,才实现了这样一个功能: 请求 /a/b/c 若文件不存在,查找 /a/b/index.php,/c 作为 PATH_INFO: 若文件不存在,查找 /a/index.php,/b/c 作为 PATH_INFO: 若文件不存在,查找 /index.php,/a/b/c 作为 PATH_INFO: 若文件不存在,返回 404. 虽然这种损耗性能的行为不适合部署,但在本机调试

  • Nginx服务器下配置个性二级域名及多个域名的实例讲解

    个性二级域名 配置下个性化二级域名. 效果: 访问的URL http://custom.jb51.net 实际的URL http://www.jb51.net/auth/custom 我们的做法就是通过服务器配置,将访问的url转换为实际的url 下面我们来用nginx配置.配置如下: server { listen 80; server_name *.jb51.net; if ( $host ~* (\b(?!www\b)\w+)\.\w+\.\w+ ) { set $subdomain $1

  • 配置ab来为Nginx服务器做压力测试的方法

    在运维工作中,压力测试是一项非常重要的工作.比如在一个网站上线之前,能承受多大访问量.在大访问量情况下性能怎样,这些数据指标好坏将会直接影响用户体验. 但是,在压力测试中存在一个共性,那就是压力测试的结果与实际负载结果不会完全相同,就算压力测试工作做的再好,也不能保证100%和线上性能指标相同.面对这些问题,我们只能尽量去想方设法去模拟.所以,压力测试非常有必要,有了这些数据,我们就能对自己做维护的平台做到心中有数. 目前较为常见的网站压力测试工具有webbench.ab(apache benc

  • 在Nginx服务器上安装配置博客程序Typecho的教程

    typecho比wordpress更轻,更专注于写的享受. 现在大多的虚拟机运行环境都是lnmp,安装教程安装typecho可能会遇到404,数据配置错误问题. 把这两天安装typecho的步骤写下来给大家参考. typecho安装方法 1.下载 #网站目录 cd /usr/local/nginx/html/ wget https://github.com/typecho/typecho/releases/download/v0.9-13.12.12-release/0.9.13.12.12.-

  • 安装配置php-fpm来搭建Nginx+PHP的生产环境

    nginx本身不能处理PHP,它只是个web服务器,当接收到请求后,如果是php请求,则发给php解释器处理,并把结果返回给客户端. nginx一般是把请求发fastcgi管理进程处理,fascgi管理进程选择cgi子进程处理结果并返回被nginx 本文以php-fpm为例介绍如何使nginx支持PHP 一.编译安装php-fpm 什么是PHP-FPM PHP-FPM是一个PHP FastCGI管理器,是只用于PHP的,可以在 http://php-fpm.org/download下载得到. P

  • Nginx服务器中location配置的一些基本要点解析

    在这一篇文章里,我将介绍nginx关于location的处理,大家都知道Nginx配置文件里面会有很多的location,nginx的配置指令的作用域可以分为 main,server,location这3个种,实际上这3者不是依次包含的关系,而是相互独立的关系,比如一个只具有main级别作用域的指令,是不能写在某个server或者location内的,模块的某个指令可以同时具有main,server,location这3种作用域,另外每个模块有 main,srv,loc这3个级别的配置,一个模块

  • Nginx配置文件中location配置的多种场景

    目录 服务请求如下(示例): 场景一. 场景二. 场景三. 场景四. 场景五. 场景六. 场景七. 场景八. 总结 服务请求如下(示例): nginx服务: http://127.0.0.1:80 后台服务:http://127.0.0.1:8088 测试url地址:http://127.0.0.1:8088/test/api/findAll 场景一. nginx配置: location /test/ { proxy_pass http://127.0.0.1:8088/; } 请求地址:htt

  • 详解nginx服务器中的安全配置

    本篇文章详细的讲诉了nginx服务器中的安全配置,具体如下: 一.关闭SELinux 安全增强型Linux(SELinux)的是一个Linux内核的功能,它提供支持访问控制的安全政策保护机制. 但是,SELinux带来的附加安全性和使用复杂性上不成比例,性价比不高 sed -i /SELINUX=enforcing/SELINUX=disabled/ /etc/selinux/config /usr/sbin/sestatus -v #查看状态 二.通过分区挂载允许最少特权 服务器上 nginx

  • Nginx中Location配置超详细讲解

    目录 一.语法 二.匹配顺序 三.root 与 alias 的区别 四.server 和 location 中的 root 总结 一.语法 Location 是 Nginx 中一个非常核心的配置,关于Location,举个简单的配置例子: server { listen 80; server_name 10.0.7.115; location / { root /data/app/; index index.html; } } 当访问 http://10.0.7.115:80 的时候,返回的是

  • Nginx服务器中的location配置详解

    语法 location  [=|~|~*|^~] /uri/  {...} 规则 = : 表示精确的URI匹配(有兴趣的同学可以看一下url和uri的区别) -: 表示区分大小写的正则匹配 -*:表示不区分大小写的正则匹配 !~ && !~*:表示区分大小写不匹配的正则和不区分大小写的不匹配的正则 /:通用匹配,任何请求都会匹配到 location匹配目标 location匹配测试只使用请求URI的部分,而不使用参数部分.(原因:参数的写法太多,无法精确匹配) location匹配顺序 多

  • 详解Nginx服务器中配置超时时间的方法

    一.啥时候用到 用来设置请求资源和服务器返回的时间,保证一个请求占用固定时间,超出后报504超时!这样可以保证一个请求占用过长时间. 二.主要参数 使用nginx服务器如果遇到timeou情况时可以如下设置参数,使用fastcgi: fastcgi_connect_timeout 75;  链接 fastcgi_read_timeout 600;   读取 fastcgi_send_timeout 600;   发请求 这两个选项.          fastcgi_read_timeout是指

  • Nginx服务器中配置非80端口的端口转发方法详解

    nginx可以很方便的配置成反向代理服务器: server { listen 80; server_name localhost; location / { proxy_pass http://x.x.x.x:9500; proxy_set_header Host $host:80; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy

  • Nginx服务器中强制使用缓存的配置及缓存优先级的讲解

    nginx代理做好了,缓存也配置好了,但是发现css.js.jpg这些静态文件统统都cached成功.但是偏偏页面文件依旧到源服务器取. 1. nginx不缓存原因 默认情况下,nginx是否缓存是由nginx缓存服务器与源服务器共同决定的, 缓存服务器需要严格遵守源服务器响应的header来决定是否缓存以及缓存的时常.header主要有如下: Cache-control:no-cache.no-store 如果出现这两值,nginx缓存服务器是绝对不会缓存的 Expires:1980-01-0

  • 在Nginx服务器中配置针对TCP的负载均衡的方法

    默认nginx不支持tcp的负载均衡,需要打补丁,(连接方式:从客户端收到一个连接,将从本地新建一个连接发起到后端服务器),具体配置如下: 一.安装Nginx 1.下载nginx # wget http://nginx.org/download/nginx-1.2.4.tar.gz 2.下载tcp模块补丁 # wget https://github.com/yaoweibin/nginx_tcp_proxy_module/tarball/master 源码主页: https://github.c

  • Nginx服务器中关于SSL的安全配置详解

    本文向你们展示如何在nginx的web服务器上设置更强的SSL.我们是通过使SSL无效来减弱CRIME攻击的这种方法实现.不使用在协议中易受攻击的SSLv3以及以下版本并且我们会设置一个更强的密码套件为了在可能的情况下能够实现Forward Secrecy,同时我们还启用HSTS和HPKP.这样我们就有了一个更强.不过时的SSL配置并且我们在Qually Labs SSL 测试中得到了A等级. 我们在nginx的设置文档中如下编辑 复制代码 代码如下: /etc/nginx/sited-enab

随机推荐