nginx详细配置说明

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 / {
	
		}
	}
}
  1. 最外层:可能包含全局配置,如 events 块和 http 块。
  2. events 块:定义了 Nginx 如何处理网络事件,如连接和读写。
  3. http 块:定义了 HTTP 服务器**(全局)**的配置。
  4. server 块:定义了**虚拟主机(不同web服务)**的配置,可以包含多个 location 块来定义不同的路径。
  5. 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;
        }
    }
}

示例:

  1. least_conn

    upstream myapp {
    	#服务器的最少连接
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
    
  2. ip_hash

    upstream myapp {
    	#根据客户端的ip
        ip_hash;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
    
  3. round_robin(默认配置轮询):

    upstream myapp {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
    
  4. random

    upstream myapp {
        random two; #随机 每个请求有两次机会选择不同的服务器
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
    
  5. fair(需要安装 ngx_http_upstream_fair_module):

    upstream myapp {
    	#响应时间
        fair;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
    
  6. 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;
    }
    
  7. 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参数的标签段位置:serverlocationif
路径重写示例:
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

对比(用户角度)
  1. URL 变化
    • 临时重定向:用户在浏览器地址栏中看到的 URL 会在短时间内变化,但最终会返回原始的 URL。
    • 永久重定向:用户在浏览器地址栏中看到的 URL 会永久性地变化,不会返回原始的 URL。
  2. 浏览体验
    • 临时重定向:用户可能会看到一个临时重定向页面,提示他们页面已被移动到另一个位置,然后被重定向到新的 URL。
    • 永久重定向:用户不会看到任何提示页面,直接被重定向到新的 URL。
  3. 搜索引擎索引
    • 临时重定向:搜索引擎可能会将新的 URL 作为原始内容的临时链接,不会立即更新索引。
    • 永久重定向:搜索引擎会将新的 URL 作为原始内容的永久链接,并更新索引。
  4. 链接权重传递
    • 临时重定向:链接权重(即 PageRank)不会从原始 URL 传递到新的 URL。
    • 永久重定向:链接权重会从原始 URL 传递到新的 URL,有助于提高新 URL 的搜索引擎排名。
  5. 文件缓存
    • 临时重定向:用户可能会从缓存中加载旧的 URL 内容,而不是新 URL 的内容。
    • 永久重定向:用户应该从缓存中加载新 URL 的内容,因为搜索引擎会将新 URL 作为原始内容的永久链接。
  6. 浏览器行为
    • 临时重定向:浏览器通常不会自动将新 URL 添加到书签或历史记录中。
    • 永久重定向:浏览器可能会将新 URL 添加到书签或历史记录中,因为它们被认为是新的 URL。

新索引。
4. 链接权重传递

  • 临时重定向:链接权重(即 PageRank)不会从原始 URL 传递到新的 URL。
  • 永久重定向:链接权重会从原始 URL 传递到新的 URL,有助于提高新 URL 的搜索引擎排名。
  1. 文件缓存
    • 临时重定向:用户可能会从缓存中加载旧的 URL 内容,而不是新 URL 的内容。
    • 永久重定向:用户应该从缓存中加载新 URL 的内容,因为搜索引擎会将新 URL 作为原始内容的永久链接。
  2. 浏览器行为
    • 临时重定向:浏览器通常不会自动将新 URL 添加到书签或历史记录中。
    • 永久重定向:浏览器可能会将新 URL 添加到书签或历史记录中,因为它们被认为是新的 URL。
  • 22
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值