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)都不一样。除非你所有请求都在一个接口里处理，才能按照你的需求来配置