前言 最近工作用到了nginx,但是路由配置特殊,业务场景复杂,因此整理了集中nginx跳转的配置方式,如servername的正则,location的匹配顺序,rewrite和proxy的示例,相信总有一种满足你的需求。 一、配置server对应的域名 server name 为虚拟服务器的识别路径。因此不同的域名会通过请求头中的HOST字段,匹配到特定的server块,转发到对应的应用服务器中去。server_name匹配规则:后面可以跟多个域名,第1个是主域名 1.1、精确匹配 如下nginx配置
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
server { listen 8080; server_name test1.com; location / { return 200 "I am test1!\n"; } } server { listen 8080; server_name my.test.com; location / { return 200 "I am mytest!\n"; } } |
请求结果 curl http://my.test.com:8080 返回:I am mytest! curl http://test1.com:8080 返回:I am test1! 1.2、正则表达式 以*通配符开始的最长字符串,如下示例
1 2 3 4 5 6 7 |
server { listen 8080; server_name test1.*; location / { return 200 "I am test1!\n"; } } |
以*通配符结束的最长字符串
1 2 3 4 5 6 |
listen 8080; server_name *.test.com; location / { return 200 "I am mytest!\n"; } } |
通配符名字只可以在名字的起始处或结尾处包含一个星号,并且星号与其他字符之间用点分隔。所以,“my..com“都是非法的。 例如 :server_name my..com; 报以下错误: nginx: [emerg] invalid server name or wildcard "my.*.com" on 0.0.0.0:8080 匹配正则表达式
1 2 3 4 5 6 7 |
server { listen 8080; server_name ~^my(?<serno>.+).mydomain.com$; location / { return 200 $serno; } } |
解释说明 ~: 表示大小写敏感的正则; ^:匹配字符串的开始; {.+}:换行符以外的任意自读重复一次活更多次; (): 分组与取值; :表示转义; serno:设置提取的变量; $:匹配字符串的结束; 请求结果
1 2 |
curl http://my02.mydomain.com:8080 返回:02% curl http://my03.mydomain.com:8080 返回:03% |
server_name的配置顺序是怎样的呢? 按照如下顺序匹配: 匹配顺序-> ->精确匹配 ->*在前的域名 ->*在后的域名 ->按文件中的顺序匹配 ->default server:第一个,listen指定default 二、配置location 2.1、Location 匹配规则:仅匹配URI,忽略参数
1 |
location [=|~|~*|^~] /uri/ { … } |
匹配的正则符号如下: = 严格匹配。如果请求匹配这个location,那么将停止搜索并立即处理此请求 ~ 区分大小写匹配(可用正则表达式) ~* 不区分大小写匹配(可用正则表达式) !~ 区分大小写不匹配 !~* 不区分大小写不匹配 ^~ 如果把这个前缀用于一个常规字符串,那么告诉nginx 如果路径匹配那么不测试正则表达式 2.2、举例
1 2 3 4 5 6 7 8 |
1、匹配任意请求 location [=|~|~*|^~] /uri/ { … } 2、不区分大小写匹配以js、php结尾的请求 location ~* .(js|php)$ { … } 3、区分大小写匹配以.txt结尾的请求 location ~ ^.+\.txt$ |
2.3、匹配顺序如下图 按照上面的规则配置了如下location
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
location = /documents { return 200 'configuration A' } location /documents { return 200 'configuration B' } location /documents/txt1 { return 200 'configuration C' } location ^~ /documents/ { return 200 'configuration D' } location ~* /documents/(\w+)$ { return 200 'configuration E' } location ~ /documents/$ { return 200 'configuration F' } |
curl […]
View DetailsNginx 读作 engine x, 是一个免费的、开源的、高性能的 HTTP 和反向代理服务,主要负责负载一些访问量比较大的站点。 Nginx 可以作为一个独立的 Web 服务,也可以用来给 Apache 或是其他的 Web 服务做反向代理。 相比于 Apache,Nginx 可以处理更多的并发连接,而且每个连接的内存占用的非常小。 本教程将会教您如何在 Centos 7 的服务器上安装和管理 Nginx。 开始前的准备 在开始阅读此教程之前,请确保你是以拥有 sudo 权限的用户来登录的服务器,并且服务器中没有 Apache 或是其他服务正在使用 80(HTTP) 和 443(HTTPS) 端口上,防止端口被占用,造成 Nginx 无法正常启动。 在 CentOS 中安装 Nginx 请按照下面的步骤,在 CentOS 中安装 Nginx。 1、 EPEL 仓库中有 Nginx 的安装包。如果你还没有安装过 EPEL,可以通过运行下面的命令来完成安装:
1 |
sudo yum install epel-release |
上面代码的意思是以 sudo 权限运行安装 epel-release,如果你当前登录的用户不是 root,则会提示你输入密码来运行,输入密码时是看不到输入的内容的,所以不用担心,继续输入就行。然后回车继续运行,后面的命令中如果包含 sudo 则都表明是刚提到的意思,不再重复解释。 2、 输入以下命令来安装 Nginx:
1 |
sudo yum install nginx |
如果这是您第一次从 EPEL 仓库中安装软件,yum 可能会提示您导入 EPEL GPG key:
1 2 3 4 5 6 7 |
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 Importing GPG key 0x352C64E5: Userid : "Fedora EPEL (7) <epel@fedoraproject.org>" Fingerprint: 91e9 7d7c 4a5e 96f1 7f3e 888f 6a2f aea2 352c 64e5 Package : epel-release-7-9.noarch (@extras) From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 Is this ok [y/N]: |
类似于上面的内容,遇到这种情况,输入 y,然后 Enter(回车) 即可继续安装。 3、 等到安装完成以后,可以通过以下命令来设置开机启动和运行 Nginx 服务: 设置 Nginx 开机启动:
1 |
sudo systemctl enable nginx |
运行以上命令以后,会输出类似以下的内容,表示创建了一个软连接来关联 Nginx,不用担心,并不是报错了,下一步就可以启动 Nginx 了。
1 |
Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service. |
启动 Nginx:
1 |
sudo systemctl start nginx |
通过运行以下命令,来检查 Nginx 的运行状态:
1 |
sudo systemctl status nginx |
然后会输出类型下面的内容 […]
View Details我的站点在443和80端口下都有部署,这样访问站点使用http和https时都可以访问到站点,但是使用http访问的站点一直会有不安全提示,这个体验很不好,就需要我们做一点工作让它自动跳转到有证书的https站点下面。 本文以站点https://www.huibenit.com为例说明怎么设置,服务器操作系统:windows2012 R2, IIS8.5 首先要做的准备是下载微软IIS下的一个Url重写模块 url-rewrite;下载地址:http://www.iis.net/downloads/microsoft/url-rewrite,目前的版本是2.1支持IIS7和IIS8。下载好后一路默认下一步安装完。 下面就开始介绍如何配置: (1)在运行里输入inetmgr打开IIS站点管理窗口,然后选择你需要设置的站点,找到Url 重写(Url rewrite)如下图所示: (2)双击“Url 重写”模块进入设置窗口,然后在右上角找到添加规则按钮,点击后如下图,再选择“空白规则”。 (3)规则设置如下: 名称:HTTPS跳转 条件:{HTTPS} 模式:off 操作类型选择:重定向 重定向URL:https://{HTTP_HOST}/{R:1} (4)最后填写完成后请点击右上角的应用(此步最重要)。 其实上面的设置过程只是一个图形操作窗口,最后填写的内容会保存在Web.Config中。我们也是可以通过修改web.config来实现上面的填写过程。 我把完整的Web.config粘贴出来如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 |
<?xml version="1.0" encoding="utf-8"?> <!-- For more information on how to configure your ASP.NET application, please visit https://go.microsoft.com/fwlink/?LinkId=301880 --> <configuration> <appSettings> <add key="webpages:Version" value="3.0.0.0" /> <add key="webpages:Enabled" value="false" /> <add key="ClientValidationEnabled" value="true" /> <add key="UnobtrusiveJavaScriptEnabled" value="true" /> </appSettings> <system.web> <compilation targetFramework="4.6.1" /> <httpRuntime targetFramework="4.6.1" /> <httpModules> <add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" /> </httpModules> </system.web> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" culture="neutral" publicKeyToken="30ad4fe6b2a6aeed" /> <bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Optimization" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="1.1.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="0.0.0.0-1.5.2.14234" newVersion="1.5.2.14234" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-5.2.3.0" newVersion="5.2.3.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Runtime.InteropServices.RuntimeInformation" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Buffers" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.2.0" /> </dependentAssembly> </assemblyBinding> </runtime> <system.webServer> <validation validateIntegratedModeConfiguration="false" /> <modules> <remove name="ApplicationInsightsWebTracking" /> <add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" preCondition="managedHandler" /> </modules> <rewrite> <rules> <rule name="HTTPS跳转" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTPS}" pattern="off" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" /> </rule> </rules> </rewrite> </system.webServer> <system.codedom> <compilers> <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701" /> <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\"Web\" /optionInfer+" /> </compilers> </system.codedom> </configuration> |
是不是很简单?只需要添加节:
1 2 3 4 5 6 7 8 9 10 11 |
<rewrite> <rules> <rule name="HTTPS跳转" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTPS}" pattern="off" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" /> </rule> </rules> </rewrite> |
from:https://lebang2020.cn/details/210106t51nqtom.html
View Details我们的系统依赖一个第三方的服务,该服务是通过IP限制访问权限的。出于安全考虑,我们的系统会校验证书,因此我们采用Nginx反向代理去访问该服务。该服务迁移到cloud上之后,我们系统出现了问题。 Nginx的配置文件如下所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
http { upstream backend.example.com { server backend1.example.com:443; } server { listen 80; server_name www.example.com; location /upstream { proxy_pass https://backend.example.com; proxy_ssl_certificate /etc/nginx/client.pem; proxy_ssl_certificate_key /etc/nginx/client.key; proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; proxy_ssl_ciphers HIGH:!aNULL:!MD5; proxy_ssl_trusted_certificate /etc/nginx/trusted_ca_cert.crt; proxy_ssl_verify on; proxy_ssl_verify_depth 2; } } } |
Debug 在出现线上问题的时候,第一时间检查了配置文件的改动记录 ⇒ 配置文件没有改到。 接着检查了,证书是否过期⇒没有过期。 通过域名curl请求 ⇒ 第三方服务正常,证书正确。 在我们没有任何改动的情况下,第三方服务也是单纯地做了迁移,然后就挂了。 思考了很久之后,Nginx没有任何改动,那么出问题的一定不是我们。那么出问题一定是第三方,最直接的方式是联系第三方提供商,联系渠道很繁琐,时间成本也会很高。为了快速修复问题,我们决定盲调Bug。 尝试解决 第一次尝试,已知curl请求一切正常。尝试着将upstream干掉,直接写道proxy_path中。依旧是失败,错误日志中出现了”https://1.1.1.1:443 TLS handshake failed”。推断,proxy_path会将域名转换成ip。 第二次尝试,尝试检查curl ip来访问服务。失败。推断,IP和域名指向了两个不同的服务。到这里算是找到root cause了。 解决思路:反向代理时候,通过域名访问而不是IP访问。 查询文档,发现可以使用配置项:proxy_ssl_server_name,该配置项默认值是off,需要将一些内容写到配置文件中:
1 |
proxy_ssl_server_name on; |
第三次尝试,将proxy_ssl_server_name on写入到配置文件中。成功。 什么是server_name 服务器名称指示(Server Name Indication, SNI)是对TLS协议的扩展。在握手过程开始时,通过该协议,客户端指示其尝试连接的主机名。该协议允许服务器上的同一个IP和TCP端口拥有多个证书,因此允许同一个IP地址为多个HTTPS网站提供服务,且无需所有网站使用相同的证书。 from:https://www.realks.com/2021/03/07/nginx-proxy-ssl-server-name/
View Details可能原因
场景1.cookie中写入的值太大造成的,因为header中的其他参数的size一般比较固定,只有cookie可能被写入较大的数据
场景2.请求参数太长,比如发布一个文章正文,用urlencode后,使用get方式传到后台。
今天使用nginx搭建了一个网站,访问后出现404错误Not found. 上网查了一下原因,是由于nginx的配置不对。因为我是有两个web目录,这两个目录在不同的位置上。而且我不想把两个目录合并在一起,所以就要配置两个location。
View Details宝塔面板如何卸载?宝塔面板是国内一款简洁易用的服务器管理面板,而有时候我们出于各种各样的原因可能需要卸载宝塔。面板既然能够安装,当然也可以卸载,下面我们介绍下卸载方法。 windows面板卸载 1.打开宝塔面板windows版安装目录,路径为:面板安装数据盘:\BtSoft\ServerAdmin 2.运行 UnInstall.exe 开始面板卸载 3.最后使用注册表清理软件或者360清理,清理注册表才可以清除服务文件。在卸载完成后,重启服务器以确保卸载干净。 linux面板卸载方法 一、脚本卸载 1.你需要先在面板中将通过面板安装的所有软件卸载,如 nginx、mysql、php 等等,然后,进入 SSH 命令行,输入以下命令: /etc/init.d/bt stop && rm -f /etc/init.d/bt && rm -rf /www/server/panel 2.或者脚本卸载更暴力一点的直接是都卸载,命令如下:
1 2 |
wget http://download.bt.cn/install/bt-uninstall.sh sh bt-uninstall.sh |
二、后续解决 虽然卸载了面板及面板环境,可是系统还是会残留一些文件,比如 www 目录,网站文件。为防止安装别的面时出现一些错误,我们可以用命令:rm –rf www 强制删除 www 文件夹。 以上是关于宝塔面板如何卸载的介绍,安装宝塔面板需要确保纯净系统安装,西部数码云服务器提供预装好宝塔面板的系统模板,可直接安装使用,如需安装请点击 https://www.west.cn/cloudhost/linux.asp from:https://www.west.cn/docs/58109.html
View Details我有一个NGINX作为我们网站的反向代理,并且运作良好.对于需要ssl的网站,我遵循 raymii.org以确保尽可能强大的SSLLabs分数.其中一个站点需要符合PCI DSS,但基于最新的TrustWave扫描现在因为启用了TLS 1.0而失败.在nginx.conf中的http级别我有:
1 |
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; |
对于我有的特定服务器:
1 |
ssl_protocols TLSv1.1 TLSv1.2; |
我已经更改了密码,将事情从http级别移到了每个ssl站点服务器,但不管我运行的是什么:
1 |
openssl s_client -connect www.example.com:443 -tls1 |
我获得了TLS 1.0的有效连接. SSLLabs将网站的nginx设置为A但是使用TLS 1.0,所以我相信其余的设置是正确的,它不会关闭TLS 1.0. 关于我可能缺少什么的想法?
1 2 3 4 5 6 7 |
openssl version -a OpenSSL 1.0.1f 6 Jan 2014 built on: Thu Jun 11 15:28:12 UTC 2015 platform: debian-amd64 nginx -v nginx version: nginx/1.8.0 |
这里的问题是TLS协商的服务器名称指示部分是在协商连接本身之后完成的.并且在连接协商期间协商协议.如果将该虚拟主机配置为没有与其关联的其他虚拟主机的服务器上的IP地址,则可能无法为该虚拟主机强制执行TLS v1.0.因此,nginx将根据IP地址知道不允许TLS v 1.0. from:http://www.voidcn.com/article/p-vufkevsw-btw.html
View Details一、问题出现 新项目采用新的前端ajax请求方式,对应的后端接口也进行了参数层面的修改。 原先在谷歌F12查看的接口请求参数打印为Query String Parameters 后续对参数进行了封装,接口请求参数打印为 。 本地测试都通过的情况下,决定上线。上线完之后对于post请求出现了请求服务器失败的情况,开始对nginx的配置进行整理和排查。 二、问题排查 原先的nginx配置如下图所示 通过对nginx日志的分析,发现了一个OPTIONS类型的请求。经过查证在请求时,OPTIONS请求是客户端的浏览器对服务端发送的一个请求,属于浏览器级行为 OPTIONS请求方法的主要用途有两个: 1、获取服务器支持的HTTP请求方法; 2、用来检查服务器的性能。例如:AJAX进行跨域请求时的预检,需要向另外一个域名的资源发送一个HTTP OPTIONS请求头,用以判断实际发送的请求是否安全。 再来看下这个“某些情况下”都是什么情况? 1、跨域请求,非跨域请求不会出现options请求 2、自定义请求头 3、请求头中的content-type是application/x-www-form-urlencoded,multipart/form-data,text/plain之外的格式 当满足条件12或者13的时候,简单的ajax请求就会出现options请求,有没有感觉到一点同源策略的意思,个人理解这个就是浏览器底层对于同源策略的一个具体实现。首先得到服务器端的确认,才能继续下一步的操作,这也是为什么options请求也被叫做“预检”请求的原因吧。 通过上面的描述,大致理解了什么是opyions请求以及options请求发送的时机,以此说明需要先处理options请求再对自己的请求做处理 三、处理方式 直接上代码了
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
location / { proxy_set_header Host $host; add_header 'Access-Control-Allow-Credentials' 'true'; add_header Access-Control-Allow-Origin "$http_origin"; add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization'; if ($request_method = 'OPTIONS') { return 204; } add_header Cache-Control no-cache; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; proxy_pass 代理地址 } |
from:https://blog.csdn.net/ATadpole/article/details/109185390
View Details