nginx配置訪問url

㈠ Nginx核心配置分析

基於域名的虛擬主機

基於埠的虛擬主機

#error_log logs/error.log notice;
**logo聲明 路徑及文件名 日誌標識**

nginx日誌切割

crontab 定時執行，切割日誌腳本
Linux Crontab 定時任務

創建 cut_ngix_log.sh 腳本

示例1：

匹配任意請求

示例2：

不區分大小寫匹配任何以 gif、jpg、jpeg 結尾的請求，並將該請求重定向到 /logo.png 請求

示例3：

區分大小寫匹配以.txt結尾的請求，並設置此location的路徑是 /usr/local/nginx/html/ 。也就是以.txt結尾的請求將訪問 /usr/local/nginx/html/ 路徑下的txt文件

root 實際訪問文件路徑會拼接URL中的路徑
alias 實際訪問文件路徑不會拼接URL中的路徑
示例如下：

在nginx中配置proxy_pass代理轉發時，如果在proxy_pass後面的url加/，表示絕對根路徑；如果沒有/，表示相對路徑，把匹配的路徑部分也給代理走。

假設下面四種情況分別用 http://192.168.1.1/proxy/test.html 進行訪問。

第一種：

代理到URL： http://127.0.0.1/test.html

第二種（相對於第一種，最後少一個 / ）

代理到URL： http://127.0.0.1/proxy/test.html

第三種：

代理到URL： http://127.0.0.1/aaa/test.html

第四種（相對於第三種，最後少一個 / ）

代理到URL： http://127.0.0.1/aaatest.html

㈡ 阿里雲slb+nginx配置curl無法獲取url問題小記

最近在做伺服器遷移, 之前是直接使用阿里雲的slb. 隨著業務的發展以及穩定性要求, 決定對伺服器進行升級, 同時對業務進行拆分, 經過多種考慮最後使用slb+nginx路由方案.

前端使用slb的tcp監聽, 開啟會話保持. ecs上配置nginx進行二次轉發.

瀏覽器訪問一切正常, 也沒有用戶報任何使用問題.

就這樣無風無雨的過了一天, 第二天業務人員報微信支付數據異常, 轉賬成功, 轉賬標識顯示失敗.

開發人員開始進行排查, 發現伺服器可以正常接收微信回調, 不過伺服器間調用出現異常.

後台日誌顯示: java.net.ConnectException: Connection timed out

我開始查看nginx日誌, 發現沒有找到請求日誌, 懷疑是nginx問題, 使用curl請求ecs, 返回值正常, 使用curl請求外網域名, curl無反饋, 看來問題出現在阿里雲的slb上面.

去網上搜了搜, 還真有人遇到同樣的問題, 只是標題是不是很一致.

解決方案是將slb的tcp監聽改為http監聽.

以下為阿里雲給出的理由:

https://help.aliyun.com/document_detail/27680.html?spm=5176.doc27671.6.240.6lfhRY

注意: 當負載均衡從4層更換到7層之後, 雖然開啟了獲取真實ip, 程序獲取真實ip還需要做一些特別的設置, 阿里雲官方文檔有詳細描述:  負載均衡 7 層 HTTP 模式獲取來訪客戶端真實 IP 的方法（IIS/Apache/Nginx/Tomcat）

附參考網址:  阿里雲SLB負載均衡https協議的一點小問題

㈢ k8s部署nginx的url反向代理初探

  團隊中做一個項目，使用Django開發多個應用，如app1、app2等，均採用docker鏡像部署到k8s環境中，整體架構為：

  常規處理方案：

  此種方案簡單清晰，對於api介面及靜態頁面（如django中的admin管理台頁面）不會產生任何問題，因為一個app對應一個域名，從邏輯上看是一對一的訪問，app之間互相隔離。

  有了這些問題，那麼我們就嘗試用url前綴去識別路由分發，實現通過url前綴進行反向代理，而不是通過域名去反向代理。
  比如/A/xxx這種url就路由到app1，/B/xxx這種url就路由到app2，依次類推。
  剛開始配置還是很簡單的，nginx配置如下：

  此配置大概意思是當匹配到帶/A/這種前綴的url時，就將請求路由到app1_addr:app1_port/中。具體location指令請參考nginx手冊。

  api介面訪問正常，但在請求 http://abc.com.cn:8080/A/admin/ ，使用django自帶的管理台時，無法進行302的跳轉。在新的url頁面無法訪問。
  經分析，過程是這樣的：

  此問題出現在第4步，需要nginx在遇到301或302時，重新修改response header中location值，這樣瀏覽器就能按添加前綴/A/後的url進行請求了。
  修改配置後如下：

  新增加一行proxy_redirect指令，具體指令說明請參見nginx手冊，大概意思是告訴nginx，當遇到301或302伺服器端重定向時，按^/(.*)$進行正則匹配，即匹配/xxxx這種url。當匹配成功後，將響應header中location值修改成 http://abc.com.cn:8080/A/$1 ，再將響應繼續返回給瀏覽器。其中$1表示正則匹配中(...)中的元組序號。
  當然，根據實際需求，還可以再添加多個proxy_rediect指令，原理一樣：

  現在api、admin管理台能訪問了，但發現管理台的js/css/html/jpg這些靜態資源都訪問失敗。
  分析如下，當django返回html到瀏覽器後，瀏覽器會解析html中靜態資源url並請求，此時靜態資源的url為/static/admin/xx/x.js或/admin/xxx/xxx這種格式。瀏覽器去請求這些url當然不存在，nginx便會直接報不存在資源。
  此時，可以有兩種方案：

  第一種方法找了找，發現不好修改，畢竟admin是django集成在安裝包中的，工程里並不會去直接繼承或二次封裝admin模塊，因此放棄了。
  第二種方法找到了nginx中sub_filter指令，再次修改如下：

  新增加sub_filter*三行指令，具體指令用法請參見手冊，大概意思是nginx根據sub_filter_types（本文沒寫，默認是text/html），去檢查每次的響應內容，若內容為text/html，則進行替換操作，將響應內容中的【/admin/】字元串替換成【/A/admin/】字元串，即增加前綴操作，static同理。最後再添加sub_filter_once off;表明上面的替換是替換響應內容的所有地方，如果不加這句指令，則只會替換一次。
  若工程中還存在其它子應用的靜態工程，也可照此來進行替換操作。
  這種替換後，原工程不用修改，不影響本地開發調試，感覺還是不錯的。

  現在api介面、admin管理台都能正常訪問了。完成了通過url前綴方式來反向代理功能。
  實現了瀏覽器或外部系統只需要通過
http://abc.com.cn:8080/A/xxxx
http://abc.com.cn:8080/B/xxxx
http://abc.com.cn:8080/C/xxxx
  這種格式的URL訪問即可，只需一個域名，僅通過/A/這種前綴來區分不同的子應用。
  一般我們會使用前後端分離去開發項目，若有必要，也可以使用sub_filter去替換相應的請求內容。

㈣ nginx問題 不同域名實現跳轉，原域名訪問url不變，怎麼樣配置nginx

proxy_pass搜一下

㈤ Nginx Rewrite 更改url參數

需求：頁面是nginx配置的反向代理，根據url匹配目錄/abtest/ 輪詢跳轉a,b兩個頁面（顯性跳轉）。參數有cid , c3 ,c6 等。根據參數c6=a|b 更改其他參數如：cid 為指定數值
輸入(2次)：
192.168.1.252/abtest/lp1.html?cid=1&c3=2&c6=a
分別頁面跳轉到：
http://192.168.1.252/ab/a/lp1.html?cid=1&c3=2&c6=a ----》echo a
http://192.168.1.252/ab/b/lp1.html?cid=1&c3=2&c6=a----- 》echo b

配置：
虛擬主機配置文件中加入(監聽a頁面的server段里)：

這里單純是修改參數的部分。 $1是前面（.*）的值，如 域名 / 後輸入的xxx.html。
$query_string 內置變數是url參數。
~* 正則匹配
$arg_參數名 接收源url參數的值 。
最後的? 號 表示不會再轉發傳遞過來原地址的問號?後面的參數那部分，最後如果不加？ 就會在更改完參數後，再次連上一段源地址的參數。
如：輸入192.168.1.252/abtest/lp1.html?cid=1&c3=2&c6=a
按照以上配置應該跳轉到 http://192.168.1.252/ab/a/lp1.html?cid=2&c3=2&c6=a
$arg_參數名最後不加? 就會顯示 http://192.168.1.252/ab/a/lp1.html?cid=2&c3=2&c6=a&cid=1&c3=2&c6=a

整體配置：

㈥ phpCMS換到nginx環境下後配置的url路由不生效，apache環境下訪問正常。

伺服器方面，如果你自己設定了url偽靜態規則，請在nginx中重新配置你的偽靜態規則。因為兩個伺服器的配置方法不一樣，在apache下可用在nginx下就不一定可用。
另外，phpcms系統方面，請確保在後頭修改url規則後已在後台-內容-更新url地址欄目下更新了所有頁面的url規則，否則也可能還是使用原來的url。

㈦ nginx 限制ip請求某個url的頻率

問題描述：
今天在統計nginx日誌中，url訪問頻率的時候，發現一個介面訪問次數遠遠大於其他的url。於是用tail -f查看實時日誌，發現有個ip以每秒3-4次請求這個url。詢問開發後，得知是第三方調用的，頻率有點高，需要限制一下。

解決：
在nginx的http模塊中添加以下配置

rate=1r/s 的意思是每個地址每秒只能請求一次

在server模塊中添加一下配置

burst是指一共有5個令牌，發完後，只能根據rate的設定每秒新增一個

reload nginx的配置之後，再次查看日誌。可以看到訪問頻率明顯降下來了

㈧ nginx配置url動態的參數如何配置

nginx按照你的需求是無法配置通用的配置。因為你每一個請求的資源定位符(uri)都不一樣。除非你所有請求都在一個介面里處理，才能按照你的需求來配置