在這一篇文章里，我將介紹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具有不同的優先級規則，大致的規則如下：