文章目录
nginx配置文件的使用,解释,示例
配置文件示例
修改nginx配置文件应该由少到多,不要增加不需要的配置
##全局配置,全局生效
# 指定nginx进程运行的用户组和用户
user www-data;
# nginx工作的进程数auto自动
worker_processes auto;
# pid文件存放地址,如果还设置了日志文件位置,这里的全局配置会覆盖下方的配置
pid /run/nginx.pid;
# 当前配置文件引用路径中的所有配置文件
include /etc/nginx/modules-enabled/*.conf;
# 事件块
events {
#指定work进程的连接数
worker_connections 768;
}
# http块 根据要求做配置
http {
#types_hash_max_size:设置用于散列表的 MIME 类型最大条数。
#include /etc/nginx/mime.types;:包含 MIME 类型的配置文件。
#default_type:设置默认 MIME 类型。
#sendfile:设置是否使用 sendfile 系统调用发送文件。
#charset:设置服务器响应的字符集。
#server_tokens:设置是否在响应中包含 Nginx 版本号。
#server_names_hash_bucket_size:设置服务器名称哈希桶的大小。
#server_name:定义服务器名称。
#listen:设置监听的端口和地址。
#server_tokens:设置是否在响应中包含 Nginx 版本号。
#root:设置网站的根目录。
#index:设置默认的索引文件。
#location:定义 URL 匹配规则和相应的处理方式。
#location =:精确匹配。
#location ~:正则表达式匹配。
#location ~*:正则表达式不区分大小写的匹配。
#location !~ 和 location !~*:正则表达式不匹配。
#location ^~:如果请求的 URI 精确匹配,则直接应用此配置,而不进一步测试其他 location。
#try_files:尝试使用多个文件,直到找到一个可以返回的文件。
#alias:定义别名,允许服务器直接访问磁盘上的文件,而不是通过根
server
{
location / {
}
}
}
- 最外层:可能包含全局配置,如
events
块和http
块。 events
块:定义了 Nginx 如何处理网络事件,如连接和读写。http
块:定义了 HTTP 服务器**(全局)**的配置。server
块:定义了**虚拟主机(不同web服务)**的配置,可以包含多个location
块来定义不同的路径。location
块:定义了特定路径的处理方式,如文件服务、重定向、缓存等。
在不同位置的include里面的配置文件的格式应该按照所处位置的格式配置
1.反向代理
nginx服务器将用户的请求在内部转发,服务端口不需要暴露。
配置文件:
server {
listen 8080;
server_name 192.168.78.200;##qinurl
location ~ / {
proxy_pass http://127.0.0.1:5244;#反向代理目标
proxy_set_header Host $host;##确保host主机头正确
proxy_set_header X-Real-IP $remote_addr;##保留客户端ip
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;##对请求客户端的ip和请求路径生成列表,用于进一步的分析和其他用途
}
}
#对目标url的请求转发到127.0.0.1:5244上
2.正向代理
正向代理需要用户在浏览器或者系统设置中正确的填写代理配置,将请求交由nginx服务器代为处理
配置文件:
server {
# 服务端口
listen 8080;
# 服务器名称,通常设置为localhost或127.0.0.1
server_name localhost;
# 设置代理服务器
location / {
# 开启正向代理
proxy_pass $scheme://$http_host$request_uri;
# 设置代理服务器将客户端的请求头转发到目标服务器
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# 其他可能需要转发的头信息
# proxy_set_header X-Forwarded-Proto $scheme;
# proxy_set_header X-Forwarded-Host $http_host;
# proxy_set_header X-Forwarded-Port $server_port;
# 禁止从代理服务器获取缓存的数据
proxy_cache_bypass $http_upgrade;
proxy_no_cache $http_upgrade;
}
}
3.负载均衡
根据需求配置
http {
# 定义后端服务器组
upstream myapp1 {
# server指令定义了后端服务器的列表
# server 服务器(域名,ip,主机名)
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
# 负载均衡方法,以下是几种常用的方法:
# least_conn:最少连接
# ip_hash:根据客户端IP分配,确保同一客户端的请求始终被分配到同一服务器
# round_robin:轮询(默认)
# random:随机分配
# fair:按照响应时间分配
# url_hash:根据请求的URL分配
# hash $request_uri consistent:一致性哈希
# load_balancing_method;
}
# 定义服务器块,处理客户端请求
server {
listen 80;
location / {
# 将请求代理到定义好的upstream
proxy_pass http://myapp1;#调用upstream
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
}
示例:
-
least_conn:
upstream myapp { #服务器的最少连接 least_conn; server srv1.example.com; server srv2.example.com; server srv3.example.com; }
-
ip_hash:
upstream myapp { #根据客户端的ip ip_hash; server srv1.example.com; server srv2.example.com; server srv3.example.com; }
-
round_robin(默认配置轮询):
upstream myapp { server srv1.example.com; server srv2.example.com; server srv3.example.com; }
-
random:
upstream myapp { random two; #随机 每个请求有两次机会选择不同的服务器 server srv1.example.com; server srv2.example.com; server srv3.example.com; }
-
fair(需要安装
ngx_http_upstream_fair_module
):upstream myapp { #响应时间 fair; server srv1.example.com; server srv2.example.com; server srv3.example.com; }
-
url_hash(需要安装
ngx_http_upstream_hash_module
):upstream myapp { #请求的url hash $request_uri; server srv1.example.com; server srv2.example.com; server srv3.example.com; }
-
consistent_hash(需要安装
ngx_http_upstream_consistent_hash_module
):upstream myapp { #url一致性 即尽可能地让相同的请求仍然被发送到同一台服务器 consistent_hash $request_uri; server srv1.example.com; server srv2.example.com; server srv3.example.com; }
4.动静分离
服务器将动态和静态资源都交由nginx处理,通过设置将二者分开请求
server {
listen 80;
server_name 192.168.17.129;
# 以/www/开头定位到/www/data/下
location /www/ {
root /data/;
index index.html index.htm;
}
# 以/image/开头定位/image/data/下
location /image/ {
root /data/;
autoindex on; // 列出访问目录
}
}
5.url重定向/重写
客户端对服务器发起请求后根据匹配规则将客户的请求url重写
放在location块下
rewrite <regex> <replacement> [flag];
关键字 正则 替代内容 flag标记
使用正则表达式表达匹配规则
- 正则:
perl
兼容正则表达式语句进行规则匹配 - 替代内容:将正则匹配的内容替换成
replacement
flag
标记:rewrite
支持的flag
标记-
-
last
:本条规则匹配完成后,继续向下匹配新的location URI规则 -
break
:本条规则匹配完成即终止,不再匹配后面的任何规则 -
redirect
:返回302临时重定向,浏览器地址会显示跳转后的URL地址 -
permanent
:返回301永久重定向,浏览器地址栏会显示跳转后的URL地址
-
rewrite
参数的标签段位置:server
,location
,if
路径重写示例:
location /old-path {
rewrite ^/old-path(.*)$/new-path$1 permanent;
}
在这个配置中,所有匹配 /old-path
的请求将被重写为 /new-path
,客户端看到的 URL 仍然是 /old-path
。但是,服务器内部会将请求处理为 /new-path
。
路径重定向示例:
location /old-path {
return 301 /new-path;
}
在这个配置中,所有匹配 /old-path
的请求将被重定向到 /new-path
,客户端看到的 URL 将会变为 /new-path
。服务器内部将不再处理 /old-path
,而是直接将请求发送到 /new-path
。
对比(主要是实际使用中的区别):
- 路径重写:服务器内部重写 URL,客户端看到的 URL 保持不变。
- 路径重定向:服务器内部重定向 URL,客户端看到的 URL 改变。
路径重写和路径重定向都可以用于 URL 优化和网站迁移,但它们的行为和用途不同。路径重写通常用于内部 URL 重写,而路径重定向用于外部 URL 重定向。
临时重定向(302 Moved Temporarily):
- 客户端应该使用新的 URL 继续请求。
- 通常用于暂时性的 URL 变更,如网站维护或页面迁移。
- 搜索引擎不会将新的 URL 作为原始内容的永久链接。
location /old-path {
return 302 /new-path;
}
在这个配置中,所有匹配 /old-path
的请求将被重定向到 /new-path
,并且客户端看到的 URL 将会变为 /new-path
。
永久重定向(301 Moved Permanently):
- 客户端应该使用新的 URL 继续请求。
- 通常用于 URL 的永久变更,如网站重定向或域名迁移。
- 搜索引擎会将新的 URL 作为原始内容的永久链接。
location /old-path {
return 301 /new-path;
}
在这个配置中,所有匹配 /old-path
的请求将被重定向到 /new-path
,并且客户端看到的 URL 将会变为 /new-path
。
对比(用户角度)
- URL 变化:
- 临时重定向:用户在浏览器地址栏中看到的 URL 会在短时间内变化,但最终会返回原始的 URL。
- 永久重定向:用户在浏览器地址栏中看到的 URL 会永久性地变化,不会返回原始的 URL。
- 浏览体验:
- 临时重定向:用户可能会看到一个临时重定向页面,提示他们页面已被移动到另一个位置,然后被重定向到新的 URL。
- 永久重定向:用户不会看到任何提示页面,直接被重定向到新的 URL。
- 搜索引擎索引:
- 临时重定向:搜索引擎可能会将新的 URL 作为原始内容的临时链接,不会立即更新索引。
- 永久重定向:搜索引擎会将新的 URL 作为原始内容的永久链接,并更新索引。
- 链接权重传递:
- 临时重定向:链接权重(即 PageRank)不会从原始 URL 传递到新的 URL。
- 永久重定向:链接权重会从原始 URL 传递到新的 URL,有助于提高新 URL 的搜索引擎排名。
- 文件缓存:
- 临时重定向:用户可能会从缓存中加载旧的 URL 内容,而不是新 URL 的内容。
- 永久重定向:用户应该从缓存中加载新 URL 的内容,因为搜索引擎会将新 URL 作为原始内容的永久链接。
- 浏览器行为:
- 临时重定向:浏览器通常不会自动将新 URL 添加到书签或历史记录中。
- 永久重定向:浏览器可能会将新 URL 添加到书签或历史记录中,因为它们被认为是新的 URL。
新索引。
4. 链接权重传递:
- 临时重定向:链接权重(即 PageRank)不会从原始 URL 传递到新的 URL。
- 永久重定向:链接权重会从原始 URL 传递到新的 URL,有助于提高新 URL 的搜索引擎排名。
- 文件缓存:
- 临时重定向:用户可能会从缓存中加载旧的 URL 内容,而不是新 URL 的内容。
- 永久重定向:用户应该从缓存中加载新 URL 的内容,因为搜索引擎会将新 URL 作为原始内容的永久链接。
- 浏览器行为:
- 临时重定向:浏览器通常不会自动将新 URL 添加到书签或历史记录中。
- 永久重定向:浏览器可能会将新 URL 添加到书签或历史记录中,因为它们被认为是新的 URL。