nginx 常見參數以及重定向參數配置

首先明白什麼是301和302

301的含義是「永久重定向」，而302的含義是「臨時重定向」。

302 重定向和網址劫持（URL hijacking）有什麼關係呢？這要從搜索引擎如何處理302轉向提及。從定義來講，從網址A作一個302重定向到網址B時，主機服務器的隱含意思是 網址A隨時有可能改主意，從新顯示自己的內容或轉向其餘的地方。大部分的搜索引擎在大部分狀況下，當收到302重定向時，通常只要去抓取目標網址就能夠 了，也就是說網址B。

實際上若是搜索引擎在遇到302轉向時，百分之百的都抓取目標網址B的話，就不用擔憂網址URL劫持了。

問 題就在於，有的時候搜索引擎，尤爲是Google，並不能老是抓取目標網址。爲何呢？好比說，有的時候A網址很短，可是它作了一個302重定向到B網 址，而B網址是一個很長的亂七八糟的URL網址，甚至還有可能包含一些問號之類的參數。很天然的，A網址更加用戶友好，而B網址既難看，又不用戶友好。這 時Google頗有可能會仍然顯示網址A。

因爲搜索引擎排名算法只是程序而不是人，在遇到302重定向的時候，並不能像人同樣的去準確斷定 哪個網址更適當，這就形成了網址URL劫持的可能性。也就是說，一個不道德的人在他本身的網址A作一個302重定向到你的網址B，出於某種緣由， Google搜索結果所顯示的仍然是網址A，可是所用的網頁內容倒是你的網址B上的內容，這種狀況就叫作網址URL劫持。你辛辛苦苦所寫的內容就這樣被別 人偷走了。

其實302的跳轉自己是沒有錯的，但由於被一些做弊者用多了，Google固然對這個就比較敏感了，畢竟Google面對的是如此海量的數據，你難道不怕被誤殺嗎？

Google的官方內容一再強調用301來轉移內容，何況，301和302在程序上的設置相差很小，既然如此，何須要冒險用302呢？

那麼就來看看nginx的配置代碼吧。

301跳轉設置：

server {
listen 80;
server_name xxx.com;
rewrite ^/(.*) http://72xit.com/$1 permanent;
access_log off;
}

302跳轉設置：

server {
listen 80;
server_name xxx.com;
rewrite ^/(.*) http://72xit.com/$1 redirect;
access_log off;
}

注意上面的permanent和redirect是不一樣的。

下面是參數

nginx 各參數翻譯，做用

$arg_PARAMETER #這個變量包含GET請求中，若是有變量PARAMETER時的值。

$args #這個變量等於請求行中(GET請求)的參數，例如foo=123&bar=blahblah;

$binary_remote_addr #二進制的客戶地址。

$body_bytes_sent #響應時送出的body字節數數量。即便鏈接中斷，這個數據也是精確的。

$content_length #請求頭中的Content-length字段。

$content_type #請求頭中的Content-Type字段。

$cookie_COOKIE #cookie COOKIE變量的值

$document_root #當前請求在root指令中指定的值。

$document_uri #與$uri相同。

$host #請求主機頭字段，不然爲服務器名稱。

$hostname #Set to the machine’s hostname as returned by gethostname

$http_HEADER

$is_args #若是有$args參數，這個變量等於」?」，不然等於」"，空值。

$http_user_agent #客戶端agent信息

$http_cookie #客戶端cookie信息

$limit_rate #這個變量能夠限制鏈接速率。

$query_string #與$args相同。

$request_body_file #客戶端請求主體信息的臨時文件名。

$request_method #客戶端請求的動做，一般爲GET或POST。

$remote_addr #客戶端的IP地址。

$remote_port #客戶端的端口。

$remote_user #已經通過Auth Basic Module驗證的用戶名。

$request_completion #若是請求結束，設置爲OK. 當請求未結束或若是該請求不是請求鏈串的最後一個時，爲空(Empty)。

$request_method #GET或POST

$request_filename #當前請求的文件路徑，由root或alias指令與URI請求生成。

$request_uri #包含請求參數的原始URI，不包含主機名，如：」/foo/bar.php?arg=baz」。不能修改。

$scheme #HTTP方法（如http，https）。

$server_protocol #請求使用的協議，一般是HTTP/1.0或HTTP/1.1。

$server_addr #服務器地址，在完成一次系統調用後能夠肯定這個值。

$server_name #服務器名稱。

$server_port #請求到達服務器的端口號。

$uri #不帶請求參數的當前URI，$uri不包含主機名，如」/foo/bar.html」。該值有可能和$request_uri 不一致。$request_uri是瀏覽器發過來的值。該值是rewrite後的值。例如作了internal redirects後。

 

 

今天在給某網站寫rewrite重定向規則時，碰到了這個關於重定向的參數處理問題。默認的狀況下，Nginx在進行rewrite後都會自動添加上舊地址中的參數部分，而這對於重定向到的新地址來講多是多餘。雖然這也不會對重定向的結果形成多少影響，但當你注意到新地址中包含有多餘的「?xxx=xxx」時，內心總仍是會以爲不爽。那麼該如何來處理這部分的內容呢？看了下面兩個簡單的例子你就會明白了。

例如：
把http://example.com/test.php?para=xxx 重定向到 http://example.com/new
若按照默認的寫法：rewrite ^/test.php(.*) /new permanent;
重定向後的結果是：http://example.com/new?para=xxx
若是改寫成：rewrite ^/test.php(.*) /new? permanent;
那結果就是：http://example.com/new

因此，關鍵點就在於「？」這個尾綴。假如又想保留某個特定的參數，那又該如何呢？能夠利用Nginx自己就帶有的$arg_PARAMETER參數來實現。

例如：
把http://example.com/test.php?para=xxx&p=xx 重寫向到 http://example.com/new?p=xx
能夠寫成：rewrite  ^/test.php   /new?p=$arg_p?  permanent;

只求結果的朋友能夠直接忽略前面的內容，看這裏：

rewrite  ^/test.php  /new  permanent;       //重寫向帶參數的地址

rewrite  ^/test.php  /new?  permanent;      //重定向後不帶參數

rewrite  ^/test.php   /new?id=$arg_id?  permanent;    //重定向後帶指定的參數

 

permanent是永久重定向參數，根據須要去掉也能夠，不過最好是帶有。

參考301重定向與302重定向的區別