當前位置:首頁 » 文件傳輸 » nginx單邊訪問
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

nginx單邊訪問

發布時間: 2022-09-02 18:31:10

❶ nginx伺服器怎麼配置瀏覽器訪問需要證書

一直在用Nginx做反向代理,但是其SSL的配置只用過普通的服務端單向證書。在Google,網路狂搜一通之後,一無所獲,依舊是那老三樣,只有單向認證的示例。瀏覽器端雙向認證的配置好像從沒人寫過。
因為要來回的設置所有直接使用域名操作比如:
chaodiquan.com 解析到 IP上面(IP要用你自己的,如果使用CDN另算)
這個是主要在最後的實際應用的測試的使用會用到

因為是自己實際應用,只好從OpenSSL的客戶端證書開始學起,一點一點啃,大段大段的E文讓我這半瓶子醋看的頭暈眼暈。
的提示下終於把這個證書搞定,來秀一個。

這需要一下幾個步驟:
1) 安裝openssl用來做證書認證
2) 創建一個CA根證書
3) 創建一個自簽名的伺服器證書
4) 設置Nginx
5) 創建客戶端證書
6) 安裝客戶端證書到瀏覽器
7) Profit.

1)
這一步我是在ubuntu下直接apt-get裝的openssl, 配置文件安裝在/etc/ssl/openssl.cnf
修改openssl.cnf的以下幾段
[ ca ]
default_ca = foo

Openssl將會尋找名稱為foo的配置段

[ foo ]
dir = /etc/ssl/private
database = $dir/index.txt
serial = $dir/serial
private_key = $dir/ca.key
certificate = $dir/ca.crt
default_days = 3650
default_md = md5
new_certs_dir = $dir
policy = policy_match

policy_match 我保持默認值沒有改

[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = match
commonName = supplied
emailAddress = optional

默認簽發有效期為10年,你可以自己設置一個合適的值

2)
創建一個新的CA根證書
下面的幾個腳本我都放在/etc/ssl目錄下

new_ca.sh:
#!/bin/sh
# Generate the key. genrsa意思是生成一個私鑰
openssl genrsa -out private/ca.key
# Generate a certificate request. req表示生成證書,還能生成ca證書,-new表示產生一個新csr,需要輸入一些信息,-key表示私鑰,
openssl req -new -key private/ca.key -out private/ca.csr
#
Self signing key is bad... this could work with a third party signed
key... registeryfly has them on for $16 but I'm too cheap lazy to get
one on a lark.
# I'm also not 100% sure if any old certificate will
work or if you have to buy a special one that you can sign with. I could
investigate further but since this
# service will never see the light of an unencrypted Internet see the cheap and lazy remark.
# So self sign our root key.
x509是一個證書生成工具,顯示證書內容,轉換格式,給CSR簽名等

-signkey用來處理CSR和給證書簽名,就像CA。使用時得同時提供私鑰,把輸入文件變成自簽名的證書,如果輸入CSR文件,則生成自簽名文件

-days證書有效時間

-in輸入文件 -out輸出文件

openssl x509 -req -days 3650 -in private/ca.csr -signkey private/ca.key -out private/ca.crt
#
Setup the first serial number for our keys... can be any 4 digit hex
string... not sure if there are broader bounds but everything I've seen
uses 4 digits.
echo FACE > private/serial
# Create the CA's key database.
touch private/index.txt

# Create a Certificate Revocation list for removing 'user certificates.'

gencrl在index文件中生成一個CRL相關的信息

-crldays是crl過期的時間
openssl ca -gencrl -out /etc/ssl/private/ca.crl -crldays 7

執行 sh new_ca.sh 生成新的CA證書

3)
生成伺服器證書的腳本

new_server.sh:
#
Create us a key. Don't bother putting a password on it since you will
need it to start apache. If you have a better work around I'd love to
hear it.
openssl genrsa -out private/server.key
# Take our key and create a Certificate Signing Request for it.
openssl req -new -key private/server.key -out private/server.csr
# Sign this bastard key with our bastard CA key.

-cert CA本身的證書名

-keyfile CA本身的私鑰

這句就是相當於CA用他的證書和私鑰,根據伺服器的證書,來給出一個CA認證的證書
openssl ca -in private/server.csr -cert private/ca.crt -keyfile private/ca.key -out private/server.crt

執行 sh new_server.sh 生成新伺服器的證書

4)
最要命的一步,嘗試多次後終於搞明白。
配置 nginx 的ssl支持

我的配置如下:

# HTTPS server
#
server {
listen 443;
server_name localhost;

# 打開ssl
ssl on;
# 上一步生成的伺服器證書
ssl_certificate /etc/ssl/private/server.crt;
# 伺服器證書公鑰
ssl_certificate_key /etc/ssl/private/server.key;
# 客戶端證書簽名 也就是第二步生成的CA簽名證書
ssl_client_certificate /etc/ssl/private/ca.crt;
# ssl session 超時
ssl_session_timeout 5m;
# 打開SSL客戶端校驗 (雙向證書檢測)
ssl_verify_client on;

#ssl_protocols SSLv2 SSLv3 TLSv1;
#ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;

location / {
root /var/www/nginx-default;
index index.html index.htm;
}

啟動你的nginx ,等待客戶連接

5)
現在來生成客戶端證書

new_user.sh:
#!/bin/sh
# The base of where our SSL stuff lives.
base="/etc/ssl/private"
# Were we would like to store keys... in this case we take the username given to us and store everything there.
mkdir -p $base/users/$1/

# Let's create us a key for this user... yeah not sure why people want to use DES3 but at least let's make us a nice big key.

生成用戶私鑰
openssl genrsa -des3 -out $base/users/$1/$1.key 1024
# Create a Certificate Signing Request for said key.

根據用戶私鑰生成他的證書
openssl req -new -key $base/users/$1/$1.key -out $base/users/$1/$1.csr
# Sign the key with our CA's key and cert and create the user's certificate out of it.

模擬CA來給出CA認證過的證書
openssl ca -in $base/users/$1/$1.csr -cert $base/ca.crt -keyfile $base/ca.key -out $base/users/$1/$1.crt

# This is the tricky bit... convert the certificate into a form that most browsers will understand PKCS12 to be specific.
#
The export password is the password used for the browser to extract the
bits it needs and insert the key into the user's keychain.
# Take the same precaution with the export password that would take with any other password based authentication scheme.

pkcs12 處理pkcs12文件
根據CA認證過的證書和用戶的私鑰來生成p12驗證證書,可用伺服器導入。
openssl pkcs12 -export -clcerts -in $base/users/$1/$1.crt -inkey $base/users/$1/$1.key -out $base/users/$1/$1.p12

執行 sh new_user.sh yourname 來生成一個 yourname 的client證書
按照提示一步一步來,這里要注意的是客戶證書的幾個項目要和根證書匹配
也就是第一步時配置的:
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = match

不一致的話無法生成最後的客戶證書

6)
發送上一步生成的 yourname.p12 到客戶端。
IE下雙擊安裝就可以導入。
FireFox安裝 :
Go into preferences.
Advanced.
View Certificates.
Import.
Enter master password for FireFox (if you don't have one set one here otherwise stolen laptop = easy access).
Enter in the export password given to you by the de who created your cert.
Hit OK like a mad man.
打開第一步進行設置的域名解析會彈出對話框來要求你選擇使用哪個證書,選擇剛才安裝的證書。選擇接受伺服器證書。現在你可以正常訪問伺服器拉。如果沒弄對的話就會出現400 Bad request certification的錯誤
7)沒啥拉,有問題多試幾次,其實都是很簡單的事。就是中文的資料太少了。
希望可以幫助到你哈

❷ nginx負載均衡怎麼訪問資料庫

nginx 是一個輕量級的、高性能的 web server 主要可以干兩件事情:

1、直接作為http server(代替apache,對PHP需要FastCGI處理器支持);
2、作為反向代理伺服器實現負載均衡

以下我們就來舉例說明如何使用 nginx 實現負載均衡。因為nginx在處理並發方面的優勢,現在這個應用非常常見。當然了Apache的 mod_proxy和mod_cache結合使用也可以實現對多台app server的反向代理和負載均衡,但是在並發處理方面apache還是沒有 nginx擅長。

方法/步驟
1
一、環境:
a. 我們本地是Windows系統,然後使用VirutalBox安裝一個虛擬的Linux系統。
在本地的Windows系統上分別安裝nginx(偵聽8080埠)和apache(偵聽80埠)。在虛擬的Linux系統上安裝apache(偵聽80埠)。
這樣我們相當於擁有了1台nginx在前端作為反向代理伺服器;後面有2台apache作為應用程序伺服器(可以看作是小型的server cluster。;-) );

b. nginx用來作為反向代理伺服器,放置到兩台apache之前,作為用戶訪問的入口;
nginx僅僅處理靜態頁面,動態的頁面(php請求)統統都交付給後台的兩台apache來處理。
也就是說,可以把我們網站的靜態頁面或者文件放置到nginx的目錄下;動態的頁面和資料庫訪問都保留到後台的apache伺服器上。

c. 如下介紹兩種方法實現server cluster的負載均衡。
我們假設前端nginx(為127.0.0.1:80)僅僅包含一個靜態頁面index.html;
後台的兩個apache伺服器(分別為localhost:80和158.37.70.143:80),一台根目錄放置phpMyAdmin文件夾和test.php(裡面測試代碼為print 「server1「;),另一台根目錄僅僅放置一個test.php(裡面測試代碼為 print 「server2「;)。

2
二、針對不同請求 的負載均衡:
a. 在最簡單地構建反向代理的時候 (nginx僅僅處理靜態不處理動態內容,動態內容交給後台的apache server來處理),我們具體的設置為:在nginx.conf中修改:
復制代碼 代碼如下:
location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}
這樣當客戶端訪問localhost:8080/index.html的時候,前端的nginx會自動進行響應;
當用戶訪問localhost:8080/test.php的時候(這個時候nginx目錄下根本就沒有該文件),但是通過上面的設置 location ~ \.php$(表示正則表達式匹配以.php結尾的文件,詳情參看location是如何定義和匹配的) ,nginx伺服器會自動pass給 158.37.70.143的apache伺服器了。該伺服器下的test.php就會被自動解析,然後將html的結果頁面返回給nginx,然後 nginx進行顯示(如果nginx使用memcached模塊或者squid還可以支持緩存),輸出結果為列印server2。
如上是最為簡單的使用nginx做為反向代理伺服器的例子;
b. 我們現在對如上例子進行擴展,使其支持如上的兩台伺服器。
我們設置nginx.conf的server模塊部分,將對應部分修改為:
復制代碼 代碼如下:
location ^~ /phpMyAdmin/ {
proxy_pass 127.0.0.1:80 ;
}
location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}
上面第一個部分location ^~ /phpMyAdmin/,表示不使用正則表達式匹配(^~),而是直接匹配,也就是如果客戶端訪問的 URL是以http://localhost:8080/phpMyAdmin/ 開頭的話(本地的nginx目錄下根本沒有phpMyAdmin目錄),nginx會自動pass到127.0.0.1:80 的Apache伺服器,該伺服器對phpMyAdmin目錄下的頁面進行解析,然後將結果發送給nginx,後者顯示;
如果客戶端訪問URL是http://localhost/test.php 的話,則會被pass到158.37.70.143:80 的apache進行處理。
因此綜上,我們實現了針對不同請求的負載均衡。
如果用戶訪問靜態頁面index.html,最前端的nginx直接進行響應;
如果用戶訪問test.php頁面的話,158.37.70.143:80 的Apache進行響應;
如果用戶訪問目錄phpMyAdmin下的頁面的話,127.0.0.1:80 的Apache進行響應;

3
三、 訪問同一頁面 的負載均衡:
即用戶訪問http://localhost:8080/test.php 這個同一頁面的時候,我們實現兩台伺服器的負載均衡 (實際情況中,這兩個伺服器上的數據要求同步一致,這里我們分別定義了列印server1和server2是為了進行辨認區別)。
a. 現在我們的情況是在windows下nginx是localhost偵聽8080埠;
兩台apache,一台是127.0.0.1:80(包含test.php頁面但是列印server1),另一台是虛擬機的158.37.70.143:80(包含test.php頁面但是列印server2)。

b. 因此重新配置nginx.conf為:
首先在nginx的配置文件nginx.conf的http模塊中添加,伺服器集群server cluster(我們這里是兩台)的定義:
復制代碼 代碼如下:
upstream myCluster {
server 127.0.0.1:80 ;
server 158.37.70.143:80 ;
}
表示這個server cluster包含2台伺服器
〉然後在server模塊中定義,負載均衡:
復制代碼 代碼如下:
location ~ \.php$ {
proxy_pass http://myCluster ; #這里的名字和上面的cluster的名字相同
proxy_ www.gzlij.comredirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
這樣的話,如果訪問http://localhost:8080/test.php 頁面的話,nginx目錄下根本沒有該文件,但是它會自動將其pass到myCluster定義的服務區機群中,分別由127.0.0.1:80;或者158.37.70.143:80;來做處理。
上面在定義upstream的時候每個server之後沒有定義權重,表示兩者均衡;如果希望某個更多響應的話例如:
復制代碼 代碼如下:
upstream myCluster {
server 127.0.0.1:80 weight=5;
server 158.37.70.143:80 ;
}

4
綜上,我們使用nginx的反向代理伺服器reverse proxy server的功能,將其布置到多台apache server的前端。
nginx僅僅用來處理靜態頁面響應和動態請求的代理pass,後台的apache server作為app server來對前台pass過來的動態頁面進行處理並返回給nginx。
通過以上的架構,我們可以實現nginx和多台apache構成的機群cluster的負載均衡。
兩種均衡:
1)可以在nginx中定義訪問不同的內容,代理到不同的後台server; 如上例子中的訪問phpMyAdmin目錄代理到第一台server上;訪問test.php代理到第二台server上;
2)可以在nginx中定義訪問同一頁面,均衡 (當然如果伺服器性能不同可以定義權重來均衡)地代理到不同的後台server上。 如上的例子訪問test.php頁面,會均衡地代理到server1或者server2上。
實際應用中,server1和server2上分別保留相同的app程序和數據,需要考慮兩者的數據同步。

❸ Linux下部署nginx為什麼永遠只訪問一台服務

總共搭建了三台伺服器

兩台tomcat伺服器

伺服器A的ip為:192.168.230.135

伺服器B的ip為:192.168.230.136

埠均為8080

還有一台nginx伺服器 IP為:192.168.230.134

nginx配置文件如下

這種情況是瀏覽器緩存的原因,你每次訪問使用 ctrl+F5 強制刷新試試。

❹ 關於nginx規則

這個涉及到nginx的路由規則的相關概念。簡單的說,就是當訪問/a時,nginx根據路由規則,把這個請求修改為/b,然後返回/b對象的內容給用戶。這個整個的路由轉換過程對用戶是透明的,也不會引起url的改變。
nginx中,可以使用rewrite指令,完成如上的功能。具體配置如下:
rewrite "^/huhe/s/(\d+)$" /huhe/dishes/rank/shopid/$1 break;

保存修改,然後重啟nginx就ok啦。

❺ nginx 只讓php入口文件訪問,其他php文件禁止直接訪問

你用的系統是微擎嗎?

正常來說,除了這兩個php文件,和回調用的介面外,其它php都是不能直接訪問的,文件頭有常量判斷,未定義就退出了。

所以你的系統有上傳漏洞,應該檢查是哪裡出了問題,並去修復一下。可以從以下幾點著手:

  1. 上傳許可權僅提供給已登錄會員,在上傳介面中判斷未登錄狀態的,直接返回錯誤信息

  2. 上傳文件類型限制,如果需要的是圖片,嚴格限制圖片類型,並做圖片規格檢測(gd庫就可以處理),不符合的不保存文件

  3. 文件名處理,不要使用客戶端上傳的文件名保存,而是根據規則 生成一個隨機的名字保存

  4. 上傳頻率限制(根據會員限制),比如,一個小時內限制上傳5張,一天限制100張,可以有效防止黑客利用上傳介面填充垃圾文件到你的伺服器

  5. 如果可行,對上傳文件做一個臨時機制,如上傳的文件先放到臨時文件夾,資料保存的時候,把文件處理一下,移動到正常的附件目錄。這樣就可以定期清理臨時文件夾,防止上傳後沒使用的文件過多佔用伺服器空間。

    不過這個功能改起來會復雜一點,要處理所有使用到上傳功能的介面。

以上幾點處理好,被上傳可執行文件的問題基本上可以杜絕了

而你的解決方案,是只治標不治本的方案

❻ 內部網路通過nginx伺服器代理訪問外部網路,要怎麼配置 注意:內部網路不能聯網。

用Nginx做反向代理服務,但是這台Nginx伺服器一定要能連接互聯網,做反向代理只能訪問部分指定網路,還有一種方式就是代理伺服器,proxy代理伺服器,這台proxy伺服器也要能連互聯網,通過在PC上代理設置可以訪問外網。

❼ 在內網通過nginx可以外網訪問指定的網站,只能訪問這一個網站。

nginx比較適用作反向代理伺服器,不過也支持正向代理

作為正向代理伺服器,可以參考下這篇博客

Linux伺服器通過Nginx正向代理上網

詳細了解nginx的正向反向代理信息,可以參考這兩篇博客

nginx功能圖解

nginx快速搭建及常用命令,策略配置,錯誤排查方法

❽ nginx只允許某IP段訪問,如何設置

是的 添的是你不能上網的IP 你用的什麼路由器?命令行模式的你就要寫一條ACL如下access-list 1 deny host 192.168.1.7-192.168.1.254 any any

❾ nginx伺服器只能在本機訪問為什麼

1.
本機系統防火牆限制其他機器的訪問
2.
網路中的防火牆設備阻斷外界訪問
3.
nginx只監聽了本地的ip埠,如127.0.0.1:80這樣其他機器訪問不了,listen指令只寫埠號即可綁定當前機器的所有ip

❿ 真心求助.nginx錯誤

Nginx伺服器錯誤一般有以下幾點原因:

1、請求的header過大。nginx默認的header長度上限是4k,如果超過了這個值,nginx會直接返回400錯誤.

解決方法:配置nginx.conf相關設置。可以通過以下2個參數來調整header上限:

client_header_buffer_size 16k;large_client_header_buffers 4 16k。

2、上傳文件過程中出現錯誤。這時瀏覽器顯示「413 Request Entity Too Large」。這是因為沒有設置client_max_body_size,這個參數默認只是1M,也就是說發布的文章內容大小不能超過1M。

解決方法:增加如下兩行到nginx.conf的http{}段, 增大nginx上傳文件大小限制:設置允許發布內容為8M:client_max_body_size 8M;client_body_buffer_size 128k。

另外如果運行的是php,那麼還要檢查php.ini,這個大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大,這樣就不會因為提交數據大小不一致出現的錯誤:post_max_size = 8M;upload_max_filesize = 6M。

修改完配置後,別忘記重新載入。

3、客戶端在為等到伺服器相應返回前就關閉了客戶端描述符。一般出現在客戶端設置超時後,伺服器主動關閉。

解決方法:根據實際Nginx後端伺服器的處理時間修改客戶端超時時間。

4、腳本錯誤(php語法錯誤、lua語法錯誤)。

解決方法:查看nginx_err_log php_err_log。

5、訪問量過大,系統資源限制,不能打開過多文件。 磁碟空間不足。(access log開啟可能導致磁碟滿溢,伺服器主動關閉)。

解決方法:修改/etc/sysctl.conf文件,並使用下面的命令確認: #sysctl -p。要使 limits.conf 文件配置生效,必須要確保 pam_limits.so 文件被加入到啟動文件中。

6、後端服務無法處理,業務中斷。

解決方法:從後端日誌獲取錯誤原因,解決後端伺服器問題。

7、後端伺服器在超時時間內,未響應Nginx代理請求。

解決方法:根據後端伺服器實際處理情況,調正後端請求超時時間。

8、網站頁面緩存過大。

解決方法:配置nginx.conf相關設置:fastcgi_buffers 8 128k;send_timeout 60。