nginx變數配置文件

A. nginx配置文件中怎麼把hostname的值賦給其它變數

Nginx 的配置文件使用的就是一門微型的編程語言，許多真實世界裡的 Nginx 配置文件其實就是一個一個的小程序。當然，是不是「圖靈完全的」暫且不論，至少據我觀察，它在設計上受 Perl 和 Bourne Shell 這兩種語言的影響很大。在這一點上，相比 Apache 和 Lighttpd 等其他 Web 伺服器的配置記法，不能不說算是 Nginx 的一大特色了。既然是編程語言，一般也就少不了「變數」這種東西（當然，Haskell 這樣奇怪的函數式語言除外了）。
熟悉 Perl、Bourne Shell、C/C++ 等命令式編程語言的朋友肯定知道，變數說白了就是存放「值」的容器。而所謂「值」，在許多編程語言里，既可以是 3.14 這樣的數值，也可以是 hello world 這樣的字元串，甚至可以是像數組、哈希表這樣的復雜數據結構。然而，在 Nginx 配置中，變數只能存放一種類型的值，因為也只存在一種類型的值，那就是字元串。
比如我們的 nginx.conf 文件中有下面這一行配置：
set $a "hello world";

我們使用了標准 ngx_rewrite 模塊的 set 配置指令對變數 $a 進行了賦值操作。特別地，我們把字元串 hello world 賦給了它。
我們看到，Nginx 變數名前面有一個 $ 符號，這是記法上的要求。所有的 Nginx 變數在 Nginx 配置文件中引用時都須帶上 $ 前綴。這種表示方法和 Perl、PHP 這些語言是相似的。
雖然 $ 這樣的變數前綴修飾會讓正統的 Java 和 C# 程序員不舒服，但這種表示方法的好處也是顯而易見的，那就是可以直接把變數嵌入到字元串常量中以構造出新的字元串：
set $a hello;
set $b "$a, $a";

這里我們通過已有的 Nginx 變數 $a 的值，來構造變數 $b 的值，於是這兩條指令順序執行完之後，$a 的值是 hello，而 $b 的值則是 hello, hello. 這種技術在 Perl 世界裡被稱為「變數插值」（variable interpolation），它讓專門的字元串拼接運算符變得不再那麼必要。我們在這里也不妨採用此術語。
我們來看一個比較完整的配置示例：
server {
listen 8080;
location /test {
set $foo hello;
echo "foo: $foo";
}
}

這個例子省略了 nginx.conf 配置文件中最外圍的 http 配置塊以及 events 配置塊。使用 curl 這個 HTTP 客戶端在命令行上請求這個 /test 介面，我們可以得到
$ curl 'http://localhost:8080/test'
foo: hello

這里我們使用第三方 ngx_echo 模塊的 echo 配置指令將 $foo 變數的值作為當前請求的響應體輸出。
我們看到，echo 配置指令的參數也支持「變數插值」。不過，需要說明的是，並非所有的配置指令都支持「變數插值」。事實上，指令參數是否允許「變數插值」，取決於該指令的實現模塊。
如果我們想通過 echo 指令直接輸出含有「美元符」（$）的字元串，那麼有沒有辦法把特殊的 $ 字元給轉義掉呢？答案是否定的（至少到目前最新的 Nginx 穩定版 1.0.10）。不過幸運的是，我們可以繞過這個限制，比如通過不支持「變數插值」的模塊配置指令專門構造出取值為 $ 的 Nginx 變數，然後再在 echo 中使用這個變數。看下面這個例子：
geo $dollar {
default "$";
}
server {
listen 8080;
location /test {
echo "This is a dollar sign: $dollar";
}
}

測試結果如下：
$ curl 'http://localhost:8080/test'
This is a dollar sign: $

這里用到了標准模塊 ngx_geo 提供的配置指令 geo 來為變數 $dollar 賦予字元串 "$"，這樣我們在下面需要使用美元符的地方，就直接引用我們的 $dollar 變數就可以了。其實 ngx_geo 模塊最常規的用法是根據客戶端的 IP 地址對指定的 Nginx 變數進行賦值，這里只是借用它以便「無條件地」對我們的 $dollar 變數賦予「美元符」這個值。
在「變數插值」的上下文中，還有一種特殊情況，即當引用的變數名之後緊跟著變數名的構成字元時（比如後跟字母、數字以及下劃線），我們就需要使用特別的記法來消除歧義，例如：
server {
listen 8080;
location /test {
set $first "hello ";
echo "${first}world";
}
}

這里，我們在 echo 配置指令的參數值中引用變數 $first 的時候，後面緊跟著 world 這個單詞，所以如果直接寫作 "$firstworld" 則 Nginx 「變數插值」計算引擎會將之識別為引用了變數 $firstworld. 為了解決這個難題，Nginx 的字元串記法支持使用花括弧在 $ 之後把變數名圍起來，比如這里的 ${first}. 上面這個例子的輸出是：
$ curl 'http://localhost:8080/test
hello world

set 指令（以及前面提到的 geo 指令）不僅有賦值的功能，它還有創建 Nginx 變數的副作用，即當作為賦值對象的變數尚不存在時，它會自動創建該變數。比如在上面這個例子中，如果 $a 這個變數尚未創建，則 set 指令會自動創建 $a 這個用戶變數。如果我們不創建就直接使用它的值，則會報錯。例如

1
2
3
4
5
6

server {
listen 8080;
location /bad {
echo $foo;
}
}

此時 Nginx 伺服器會拒絕載入配置:

1

[emerg] unknown "foo" variable

是的，我們甚至都無法啟動服務！
有趣的是，Nginx 變數的創建和賦值操作發生在全然不同的時間階段。Nginx 變數的創建只能發生在 Nginx 配置載入的時候，或者說 Nginx 啟動的時候；而賦值操作則只會發生在請求實際處理的時候。這意味著不創建而直接使用變數會導致啟動失敗，同時也意味著我們無法在請求處理時動態地創建新的 Nginx 變數。
Nginx 變數一旦創建，其變數名的可見范圍就是整個 Nginx 配置，甚至可以跨越不同虛擬主機的 server 配置塊。我們來看一個例子：
server {
listen 8080;
location /foo {
echo "foo = [$foo]";
}
location /bar {
set $foo 32;
echo "foo = [$foo]";
}
}

這里我們在 location /bar 中用 set 指令創建了變數 $foo，於是在整個配置文件中這個變數都是可見的，因此我們可以在 location /foo 中直接引用這個變數而不用擔心 Nginx 會報錯。
下面是在命令行上用 curl 工具訪問這兩個介面的結果：

$ curl 'http://localhost:8080/foo'
foo = []

$ curl 'http://localhost:8080/bar'
foo = [32]

$ curl 'http://localhost:8080/foo'
foo = []

從這個例子我們可以看到，set 指令因為是在 location /bar 中使用的，所以賦值操作只會在訪問 /bar 的請求中執行。而請求 /foo 介面時，我們總是得到空的 $foo 值，因為用戶變數未賦值就輸出的話，得到的便是空字元串。
從這個例子我們可以窺見的另一個重要特性是，Nginx 變數名的可見范圍雖然是整個配置，但每個請求都有所有變數的獨立副本，或者說都有各變數用來存放值的容器的獨立副本，彼此互不幹擾。比如前面我們請求了 /bar 介面後，$foo 變數被賦予了值 32，但它絲毫不會影響後續對 /foo 介面的請求所對應的 $foo 值（它仍然是空的！），因為各個請求都有自己獨立的 $foo 變數的副本。
對於 Nginx 新手來說，最常見的錯誤之一，就是將 Nginx 變數理解成某種在請求之間全局共享的東西，或者說「全局變數」。而事實上，Nginx 變數的生命期是不可能跨越請求邊界的。

B. nginx中proxy_set_header Host $host;的作用！~請詳解！~

用戶認證介面：根據客戶端IP和port，進行IP反查和埠范圍確認，如符合則用戶認證通過。

proxy_set_header 就是可設置請求頭-並將頭信息傳遞到伺服器端。

1、Nginx proxy_set_header
允許重新定義或添加欄位傳遞給代理伺服器的請求頭。該值可以包含文本、變數和它們的組合。在沒有定義proxy_set_header時會繼承之前定義的值。默認情況下，只有兩個欄位被重定義：

C. Nginx配置文件詳解

說到該指令 ，首先得闡述一下什麼是所謂的 「驚群問題」，可以參考 WIKI網路的解釋。就Nginx的場景來解釋的話大致的意思就是：當一個新網路連接來到時，多個worker進程會被同時喚醒，但僅僅只有一個進程可以真正獲得連接並處理之。如果每次喚醒的進程數目過多的話，其實是會影響一部分性能的。

所以在這里，如果accept_mutex on，那麼多個worker將是以串列方式來處理，其中有一個worker會被喚醒；反之若accept_mutex off，那麼所有的worker都會被喚醒，不過只有一個worker能獲取新連接，其它的worker會重新進入休眠狀態。

用rewrite轉發的話，url會發生變化的，那就用proxy_pass吧，於是添加了如下的配置：

在現有環境的nginx里添加這段配置之後，訪問卻始終轉不過去，查看nginx日誌也只能看到是404信息，並沒有更多定位問題的信息。檢查了許久也沒找到原因，於是重新裝了一台新nginx，裡面只加上面這段配置，結果nginx是能夠轉發成功的，這說明單獨來看這條location的配置是沒有問題的，很有可能是現有環境nginx里的某些配置影響到了這個轉發。

為了定位問題原因，我將aaa.example.com虛擬主機下的其他配置注意注釋掉來調試，最後發現當注釋掉proxy_set_header Host $http_host ;這條配置之後，就能成功轉發了。這才注意到是反向代理配置的問題。現有環境中原有的配置也不能隨便刪掉，上網查了下原因，找到下面這種解決方案：

即，在location裡面添加一條proxy_set_header Host http_host時，則不改變請求頭的值，所以當要轉發到bbb.example.com的時候，請求頭還是aaa.example.com的Host信息，就會有問題；當Host設置為$proxy_host時，則會重新設置請求頭為bbb.example.com的Host信息。

另外，關於proxy_pass轉發url的參數，可以通過在location中用rewrite來做，所以完善後的配置如下：

在location用rewrite改變了URI之後，proxy_pass將使用改變後的URI。上面例子(.*)是將所有參數傳給 1會拼接在 http://bbb.example.com 後面。

先來看下proxy_set_header的語法

允許重新定義或者添加發往後端伺服器的請求頭。value可以包含文本、變數或者它們的組合。 當且僅當當前配置級別中沒有定義proxy_set_header指令時，會從上面的級別繼承配置。 默認情況下，只有兩個請求頭會被重新定義：

當匹配到/customer/straightcustomer/download時，使用crmtest處理，到upstream就匹配到crmtest.aty.sohuno.com，這里直接轉換成IP進行轉發了。假如crmtest.aty.sohuno.com是在另一台nginx下配置的，ip為10.22.10.116，則$proxy_host則對應為10.22.10.116。此時相當於設置了Host為10.22.10.116。如果想讓Host是crmtest.aty.sohuno.com，則進行如下設置：

如果不想改變請求頭「Host」的值，可以這樣來設置：

但是，如果客戶端請求頭中沒有攜帶這個頭部，那麼傳遞到後端伺服器的請求也不含這個頭部。 這種情況下，更好的方式是使用$host變數——它的值在請求包含「Host」請求頭時為「Host」欄位的值，在請求未攜帶「Host」請求頭時為虛擬主機的主域名：

此外，伺服器名可以和後端伺服器的埠一起傳送：

如果某個請求頭的值為空，那麼這個請求頭將不會傳送給後端伺服器：

nginx配置項，裡面的配置項有代理https，http，代理靜態文件，H5分發，代理TCP連接，能滿足大多數搭建測試環境所要用的nginx的情況，大家碰到要使用nginx的時候可以參考下

D. 如何跟蹤nginx配置文件里的變數

nginx模塊一般被分成三大類：handler、filter和upstream。前面的章節中，讀者已經了解了handler、filter。利用這兩類模塊，可以使nginx輕松完成任何單機工作。而本章介紹的upstream模塊，將使nginx跨越單機的限制，完成網路數據的接收、處理和轉..

E. Nginx $host變數詳解

host變數的值按照如下優先順序獲得：

我們知道，HTTP是一個文本協議，建立在一個可靠的傳輸層協議之上。這個傳輸層協議要是可靠的，面向連接的。由於TCP的普及程度，讓它成了HTTP下層協議事現上的標准。但我們要知道，HTTP並不僅限於建立在TCP之上。只要是可靠的，面向連接的傳輸層協議，都可以用來傳輸HTTP。下面所說的HTTP，都是指搭載在TCP之上的HTTP。

一個HTTP請求過程是這樣的，客戶端先與伺服器建立起TCP連接，然後再與伺服器端進行請求和回復的收發。請求包含請求行、請求頭和請求體，其中，根據請求方法的不同，請求體是可選的。

在發送請求行之前，客戶端與伺服器已經建立了連接。所以此時請求行中並不需要有伺服器的信息。我們用telnet測試, 例如:

這就是一個完整的HTTP請求行。雖然請求行中不需要有伺服器的信息，但仍然可以在請求行中包含伺服器的信息。例如：

兩者一比較，就很容易理解什麼叫請求行中的host了。第一個請求行中，就沒有host，第二種請求行中，就帶了host，為 www.test.info 。

一個請求，請求行下面就是一些列的請求頭。這些請求頭，在HTTP/1.0中，都是可選的，且HTTP/1.0不支持Host請求頭； 而在HTTP/1.1中，Host請求頭部必須存在 ,否則會返回400 Bad Request
我們看個例子, 使用telnet 連接:

但是HTTP/1.0是不支持Host頭部的,所以請求,不需要帶這個Host,我們也測試一下:

可以看到沒有返回400， 而是返回了404，說明這個請求還是來到nginx處理，命中了其中一個配置的"虛擬主機", 我到nginx下面看access_log，看到日誌寫在了第一個的nginx虛擬主機配置的日誌文件下面，說明http1.0情況下，沒有帶host頭部，請求默認來到了nginx 第一個虛擬主機下處理。

server name是指在Nginx配置文件中，在server塊中，用server_name指令設置的值。一個server可以多次使用server_name指令，來實現俗稱的「虛擬主機」。例如：

關於虛擬主機的確定方法，還是引用Nginx的官方文檔：

這就解釋了上面的HTTP1.0請求，不帶Host頭，默認來到了第一個配置的server處理了。
然後我測試一下把 www.test.info 這個域名設成默認的主機default_server，看請求能不能正常來到 www.test.info 這個server來處理。

nginx 配置修改：

再次請求：

實際測試，正常，default_server確實起作用了。

http_host 則是讀取請求頭header裡面的key，所有請求頭裡面的key再nginx裡面都可以通過小寫和下劃線來讓nginx讀取。例如header裡面的Host就能轉成 http_user_agent。
所以，只要是header的請求頭都可以這樣被nginx讀取， 我們測試一下：

當然這個幾個頭部能在response顯示是因為在nginx加了add_header控制的：

$http_header的應用：當我們一個項目部署在兩個伺服器下面，然後在另外一個伺服器搭建nginx反響代理，反響代理把請求轉發給兩個伺服器的時候，他們的日誌記錄的是反向代理的ip， 而不是真正請求的用戶IP， 這時就可以通過配置proxy_set_header 把真實IP設置給一個X-forwarded-For 或者 X-Real-IP 轉給後端伺服器，然後後端伺服器讀取通過http_x_real_ip來讀取真實IP， 記錄到access_log下面

日誌的格式把第一個IP換成剛才轉發過來的頭部X-Real-IP就可以記錄用戶IP了：

關於nginx中的host變數
What's the difference of http_host in Nginx

F. 「微服務架構」部署NGINX Plus作為API網關，第1部分 - NGINX

了解著名的Nginx伺服器（微服務必不可少的東西）如何用作API網關。

現代應用程序體系結構的核心是HTTP API。 HTTP使應用程序能夠快速構建並輕松維護。無論應用程序的規模如何，HTTP API都提供了一個通用介面，從單用途微服務到無所不包的整體。通過使用HTTP，支持超大規模Internet屬性的Web應用程序交付的進步也可用於提供可靠和高性能的API交付。

有關API網關對微服務應用程序重要性的精彩介紹，請參閱我們博客上的構建微服務：使用API​​網關。

作為領先的高性能，輕量級反向代理和負載均衡器，NGINX Plus具有處理API流量所需的高級HTTP處理功能。這使得NGINX Plus成為構建API網關的理想平台。在這篇博文中，我們描述了許多常見的API網關用例，並展示了如何配置NGINX Plus以便以高效，可擴展且易於維護的方式處理它們。我們描述了一個完整的配置，它可以構成生產部署的基礎。

注意：除非另有說明，否則本文中的所有信息均適用於NGINX Plus和NGINX開源。

API網關的主要功能是為多個API提供單一，一致的入口點，無論它們在後端如何實現或部署。並非所有API都是微服務應用程序。我們的API網關需要管理現有的API，單塊和正在部分過渡到微服務的應用程序。

在這篇博文中，我們引用了一個假設的庫存管理API，即「倉庫API」。我們使用示例配置代碼來說明不同的用例。 Warehouse API是一個RESTful API，它使用JSON請求並生成JSON響應。但是，當部署為API網關時，使用JSON不是NGINX Plus的限制或要求; NGINX Plus與API本身使用的架構風格和數據格式無關。

Warehouse API實現為離散微服務的集合，並作為單個API發布。庫存和定價資源作為單獨的服務實施，並部署到不同的後端。所以API的路徑結構是：

例如，要查詢當前倉庫庫存，客戶端應用程序會向/ api / warehouse / inventory發出HTTP GET請求。

使用NGINX Plus作為API網關的一個優點是，它可以執行該角色，同時充當現有HTTP流量的反向代理，負載平衡器和Web伺服器。如果NGINX Plus已經是應用程序交付堆棧的一部分，那麼通常不需要部署單獨的API網關。但是，API網關所期望的某些默認行為與基於瀏覽器的流量的預期不同。出於這個原因，我們將API網關配置與基於瀏覽器的流量的任何現有（或未來）配置分開。

為實現這種分離，我們創建了一個支持多用途NGINX Plus實例的配置布局，並為通過CI / CD管道自動配置部署提供了便利的結構。 / etc / nginx下的結果目錄結構如下所示。

所有API網關配置的目錄和文件名都以api_為前綴。這些文件和目錄中的每一個都啟用API網關的不同特性和功能，並在下面詳細說明。

所有NGINX配置都以主配置文件nginx.conf開頭。要讀入API網關配置，我們在nginx.conf的http塊中添加一個指令，該指令引用包含網關配置的文件api_gateway.conf（下面的第28行）。請注意，默認的nginx.conf文件使用include偽指令從conf.d子目錄中引入基於瀏覽器的HTTP配置（第29行）。本博文廣泛使用include指令來提高可讀性並實現配置某些部分的自動化。

api_gateway.conf文件定義了將NGINX Plus公開為客戶端的API網關的虛擬伺服器。此配置公開API網關在單個入口點https://api.example.com/（第13行）發布的所有API，受第16到21行配置的TLS保護。請注意，此配置純粹是HTTPS - 沒有明文HTTP偵聽器。我們希望API客戶端知道正確的入口點並默認進行HTTPS連接。

此配置是靜態的 - 各個API及其後端服務的詳細信息在第24行的include偽指令引用的文件中指定。第27到30行處理日誌記錄默認值和錯誤處理，並在響應中討論錯誤部分如下。

一些API可以在單個後端實現，但是出於彈性或負載平衡的原因，我們通常期望存在多個API。使用微服務API，我們為每個服務定義單獨的後端;它們一起作為完整的API。在這里，我們的Warehouse API被部署為兩個獨立的服務，每個服務都有多個後端。

API網關發布的所有API的所有後端API服務都在api_backends.conf中定義。這里我們在每個塊中使用多個IP地址 - 埠對來指示API代碼的部署位置，但也可以使用主機名。 NGINX Plus訂戶還可以利用動態DNS負載平衡，自動將新後端添加到運行時配置中。

配置的這一部分首先定義Warehouse API的有效URI，然後定義用於處理對Warehouse API的請求的公共策略。

Warehouse API定義了許多塊。 NGINX Plus具有高效靈活的系統，可將請求URI與配置的一部分進行匹配。通常，請求由最具體的路徑前綴匹配，並且位置指令的順序並不重要。這里，在第3行和第8行，我們定義了兩個路徑前綴。在每種情況下，$ upstream變數都設置為上游塊的名稱，該上游塊分別代表庫存和定價服務的後端API服務。

此配置的目標是將API定義與管理API交付方式的策略分開。為此，我們最小化了API定義部分中顯示的配置。在為每個位置確定適當的上游組之後，我們停止處理並使用指令來查找API的策略（第10行）。

使用重寫指令將處理移至API策略部分

重寫指令的結果是NGINX Plus搜索匹配以/ _warehouse開頭的URI的位置塊。第15行的位置塊使用=修飾符執行完全匹配，從而加快處理速度。

在這個階段，我們的政策部分非常簡單。位置塊本身標記為第16行，這意味著客戶端無法直接向它發出請求。重新定義$ api_name變數以匹配API的名稱，以便它在日誌文件中正確顯示。最後，請求被代理到API定義部分中指定的上游組，使用$ request_uri變數 - 其中包含原始請求URI，未經修改。

API定義有兩種方法 - 廣泛而精確。每種API最合適的方法取決於API的安全要求以及後端服務是否需要處理無效的URI。

在warehouse_api_simple.conf中，我們通過在第3行和第8行定義URI前綴來使用Warehouse API的廣泛方法。這意味著以任一前綴開頭的任何URI都代理到相應的後端服務。使用基於前綴的位置匹配，對以下URI的API請求都是有效的：

如果唯一的考慮是將每個請求代理到正確的後端服務，則廣泛的方法提供最快的處理和最緊湊的配置。另一方面，精確的方法使API網關能夠通過顯式定義每個可用API資源的URI路徑來理解API的完整URI空間。採用精確的方法，Warehouse API的以下配置使用精確匹配（=）和正則表達式（〜）的組合來定義每個URI。

此配置更詳細，但更准確地描述了後端服務實現的資源。這具有保護後端服務免於格式錯誤的客戶端請求的優點，代價是正常表達式匹配的一些小額外開銷。有了這個配置，NGINX Plus接受一些URI並拒絕其他URI無效：

使用精確的API定義，現有的API文檔格式可以驅動API網關的配置。可以從OpenAPI規范（以前稱為Swagger）自動化NGINX Plus API定義。此博客文章的Gists中提供了用於此目的的示例腳本。

隨著API的發展，有時會發生需要更新客戶端的重大更改。一個這樣的示例是重命名或移動API資源。與Web瀏覽器不同，API網關無法向其客戶端發送命名新位置的重定向（代碼301）。幸運的是，當修改API客戶端不切實際時，我們可以動態地重寫客戶端請求。

在下面的示例中，我們可以在第3行看到定價服務以前是作為庫存服務的一部分實現的：rewrite指令將對舊定價資源的請求轉換為新的定價服務。

動態重寫URI意味著當我們最終在第26行代理請求時，我們不能再使用$ request_uri變數（正如我們在warehouse_api_simple.conf的第21行所做的那樣）。這意味著我們需要在API定義部分的第9行和第14行使用稍微不同的重寫指令，以便在處理切換到策略部分時保留URI。

HTTP API和基於瀏覽器的流量之間的主要區別之一是如何將錯誤傳達給客戶端。當NGINX Plus作為API網關部署時，我們將其配置為以最適合API客戶端的方式返回錯誤。

頂級API網關配置包括一個定義如何處理錯誤響應的部分。

第27行的指令指定當請求與任何API定義都不匹配時，NGINX Plus會返回錯誤而不是默認錯誤。此（可選）行為要求API客戶端僅向API文檔中包含的有效URI發出請求，並防止未經授權的客戶端發現通過API網關發布的API的URI結構。

第28行指的是後端服務本身產生的錯誤。未處理的異常可能包含我們不希望發送到客戶端的堆棧跟蹤或其他敏感數據。此配置通過向客戶端發送標准化錯誤來進一步提供保護。

完整的錯誤響應列表在第29行的include偽指令引用的單獨配置文件中定義，其前幾行如下所示。如果首選不同的錯誤格式，並且通過更改第30行上的default_type值以匹配，則可以修改此文件。您還可以在每個API的策略部分中使用單獨的include指令來定義一組覆蓋默認值的錯誤響應。

有了這種配置，客戶端對無效URI的請求就會收到以下響應。

在沒有某種形式的身份驗證的情況下發布API以保護它們是不常見的。 NGINX Plus提供了幾種保護API和驗證API客戶端的方法。有關基於IP地址的訪問控制列表（ACL），數字證書身份驗證和HTTP基本身份驗證的信息，請參閱文檔。在這里，我們專注於API特定的身份驗證方法。

API密鑰身份驗證

API密鑰是客戶端和API網關已知的共享密鑰。它們本質上是作為長期憑證發布給API客戶端的長而復雜的密碼。創建API密鑰很簡單 - 只需編碼一個隨機數，如本例所示。

在頂級API網關配置文件api_gateway.conf的第6行，我們包含一個名為api_keys.conf的文件，其中包含每個API客戶端的API密鑰，由客戶端名稱或其他描述標識。

API密鑰在塊中定義。 map指令有兩個參數。第一個定義了API密鑰的位置，在本例中是在$ http_apikey變數中捕獲的客戶端請求的apikey HTTP頭。第二個參數創建一個新變數（$ api_client_name）並將其設置為第一個參數與鍵匹配的行上的第二個參數的值。

例如，當客戶端提供API密鑰7B5zIqmRGXmrJTFmKa99vcit時，$ api_client_name變數設置為client_one。此變數可用於檢查經過身份驗證的客戶端，並包含在日誌條目中以進行更詳細的審核。

地圖塊的格式很簡單，易於集成到自動化工作流程中，從現有的憑證存儲生成api_keys.conf文件。 API密鑰身份驗證由每個API的策略部分強制執行。

客戶端應在apikey HTTP頭中顯示其API密鑰。如果此標頭丟失或為空（第20行），我們發送401響應以告知客戶端需要進行身份驗證。第23行處理API鍵與地圖塊中的任何鍵都不匹配的情況 - 在這種情況下，api_keys.conf第2行的默認參數將$ api_client_name設置為空字元串 - 我們發送403響應告訴身份驗證失敗的客戶端。

有了這個配置，Warehouse API現在可以實現API密鑰身份驗證。

JWT身份驗證

JSON Web令牌（JWT）越來越多地用於API身份驗證。原生JWT支持是NGINX Plus獨有的，可以在我們的博客上驗證JWT，如使用JWT和NGINX Plus驗證API客戶端中所述。

本系列的第一篇博客詳細介紹了將NGINX Plus部署為API網關的完整解決方案。可以從我們的GitHub Gist倉庫查看和下載此博客中討論的完整文件集。本系列的下一篇博客將探討更高級的用例，以保護後端服務免受惡意或行為不端的客戶端的攻擊。

原文：https://dzone.com/articles/deploying-nginx-plus-as-an-api-gateway-part-1-ngin

本文：http://pub.intelligentx.net/deploying-nginx-plus-api-gateway-part-1-nginx

討論：請加入知識星球或者小紅圈【首席架構師圈】