nginx的index用法(nginx xforwardfor)

nginx的index用法

估计是你的80端口么有打开吧，你可以参考下面的配置教程。

nginx xforwardfor

Nginx 跟 Haproxy 其实他们两个的定位是有所不同的，Nginx的定位是一个server，Haproxy的定位是一个load balancer。

Nginx通过各种plugin module可以支持Load balance的功能，而且性能不弱于haproxy太多，所以总有人拿来将两个东西比较。其实Apache也可以通过相关模块做load balancer，只不过性能差得多而已所以没人用而已。当然了Nginx的LB功能现在是其支柱主打功能而已。

看到有很多答案对于haproxy多进程有误解，这里特别说下，haproxy早就支持多进程模型，但是并不是Nginx的Worker Master结构，而是平等多进程结构，同时也支持REUSE PORT选项，所以在这里Nginx跟Haproxy对于多核利用上都是一样的并没有本质区别。

haproxy从1.8之后，添加了多线程的模式，现在它更推荐的也是这个模型，在一些平台上能够更好的利用多核。而Nginx从来没有多线程模型。而且看起来社区也没打算支持。

Nginx其实基于server的功能来说，是Haproxy不具备的，让Haproxy像一个普通Web server那样回复一个普通的HTTP请求是很难的，不大规模修改源码根本做不到。Haproxy是围绕转发模型设计的，整个流程就是围绕如何快速把一个请求或者回复转发到另一端。并不是像Server一样接受请求然后回复。

但是Nginx作为一个纯粹的LB来说，尤其是针对Web LoadBalancer来说，功能没有haproxy那么细致。Haproxy支持的ACL对象非常广泛，很多情况并不需要脚本辅助就可以完成复杂的功能，而Nginx稍微复杂的LoadBalance功能都需要使用脚本才能完成，这样性能就会差很多。

从功能角度上来讲，Nginx其实功能比Haproxy要多（当然并不都是免费的），因为他的开发社区和定位方向都比Haproxy要大和宽泛。在Nginx上面的各种解决方案也要多的多。比如WAF，haproxy一致都没有比较好的原生解决方案。还有包括最近针对Service Mesh的支持，haproxy都是很难跟得上。

但是基础功能，包括HTTP2，TLS 1.3，Script， SSL/TLS offload，ocsp，SNI preload，其实haproxy最新版本早就已经支持，甚至比Nginx还更早些（HTTP2比较晚，但是现在也支持了）。另外，关于硬件SSL offload支持其实主要是OpenSSL的engine的支持，所以这个大家都差不多，只要兼容最新OpenSSL都没什么问题。

Haproxy的优点其实是转发性能稍高，因为haproxy追求zero copy的forward流程，所以代码都倾向于优化在这一点上。但是这个优势现在被广泛的TLS/SSL应用抹平了，对比0 copy节省的时间来说加解密的消耗的性能占绝大多数，所以haproxy基本上在现在的广泛SSL环境下没有什么优势了。除非你想用纯HTTP，而且还想使用比较复杂的基于HTTP头部的Load Balance功能，那么Haproxy是个好选择，否则只是单纯LB的话，LVS性能其实更更高，毕竟人家在Kernel里面。

从代码层面来说，Nginx的结构化代码和模块化都比Haproxy好太多。Haproxy代码模块化一直是个大问题，内部结构模块化不足，二次开发困难，最近到1.9了才有些改善，但是仍然有很多内部trick的hack和让人发懵的FLAG。相比Nginx做到的彻底的模块化，可以轻易的通过开发自己的模块来改变或者实现相关功能，这个haproxy是不具备的。

从开发社区来说，Nginx也比Haproxy好太多，Haproxy虽然社区历史更久，但是一直都是不愠不火，贡献者因为原作者的严格的控制，一直都很少，再加上没有module开发功能，所以吸引的开发者一直都不多。带来的问题就是版本更新慢，支持的新功能慢。HTTP2的开发完全靠原作者一个人，所以支持进度严重拖后。

这篇文章看起来好像是变成了对haproxy吐槽，但是因为在工作中接触这两个东西实在太多，而且是进行深度二次开发，所以自认为还是有一定的了解的。从目前来看，如果haproxy不能更开放招募更多的贡献者，不能彻底修改架构支持module开发，是无法比拟NGINX的。

另外Haproxy优势一点的就是免费版的功能比Nginx免费版的更实惠。对于小又穷的站点的确是个好处。

nginx的include

以vue框架为例，在nginx.conf中监听80或443端口的server的路由配置设置为：

location ^~ /api { # url如/api/v1.0/user/info等，通过uwsgi转发到django后端项目中处理

include /etc/nginx/uwsgi_params;

uwsgi_pass 127.0.0.1:8077;

include /etc/nginx/mime.types;

}

location ^~ /static { # 后端的资源文件夹为static，前端请求后端项目包内的静态文件

root /root/backend_end_project/static/;

}

location ^~ /admin { # django的后台管理页面通过uwsgi转交给django处理

include /etc/nginx/uwsgi_params;

uwsgi_pass 127.0.0.1:8077;

include /etc/nginx/mime.types;

}

location ^~ /assets { # 前端的资源文件夹为assets，前端请求前端项目包内的静态文件

root /root/front_end_project/dist;

}

location / { # 表示其它路径都交给前端项目根目录下的index.html处理

root /root/front_end_project;

try_files $uri /index.html;

}

nginx index

1、作为Web服务器，Nginx处理静态文件、索引文件，自动索引的效率非常高

2、作为代理服务器，Nginx可以实现无缓存的反向代理加速，提高网站运行速度

3、作为负载均衡服务器，Nginx既可以在内部直接支持Rails和PHP，也可以支持HTTP代理服务器对外进行服务，同时还支持简单的容错和利用算法进行负载均衡

4、在性能方面，Nginx是专门为性能优化而开发的，实现上非常注重效率。它采用内核Poll模型，可以支持更多的并发连接，最大可以支持对5万个并发连接数的响应，而且只占用很低的内存资源

5、在稳定性方面，Nginx采取了分阶段资源分配技术，使得CPU与内存的占用率非常低。Nginx官方表示，Nginx保持1万个没有活动的连接，而这些连接只占用2.5MB内存，因此，类似DOS这样的攻击对Nginx来说基本上是没有任何作用的

6、在高可用性方面，Nginx支持热部署，启动速度特别迅速，因此可以在不间断服务的情况下，对软件版本或者配置进行升级，即使运行数月也无需重新启动，几乎可以做到7x24小时不间断地运行

7、内置的健康检查功能：如果有一个服务器宕机，会做一个健康检查，再发送的请求就不会发送到宕机的服务器了。重新将请求提交到其他的节点上。

nginx 使用

1.后缀问题，用Nginx的rewrite就行

2.restful权限你已经用了JWT，那么返回的JWT存进localstorage,页面在每次加载的时候拉取存的JWT的token，如果不存在重定向至登陆页面，如果存在带进头部

Authentication

3.限制带html后缀访问，你可以在nginx写个正则

nginx index配置

nginx配置如下： 

1、定义worker进程数： 

worker_processes 10;

2、定义worker进程可同时服务请求数目：

worker_connections 1024;

3、禁止使用sendfile函数：

sendfile off;

4、开启空闲连接的文件检查：

linger_on_close on;

5、定义多个进程间通信存放文件路径及名称：

pid /var/run/nginx.pid;

6、定义用户和组：

user nobody nogroup;

7、定义worker进程数量：

worker_processes 10;

8、定义最大请求进程时间：

client_body_timeout 10; 

9、定义服务的超时时间：

send_timeout 10;

10、打开目录列表功能：

autoindex on;

nginx index of

我的回答：nginx配置系统登陆页，可以在Nginx的配置文件nginx.conf中配置。

nginx.conf配置文件中server{...}模块里面有 index可以指定系统的系统登录页，一般默认是：index index.html index.htm index.php;

可以把默认的系统登录页文件名靠前写。

nginx !-e

从nginx官网下载相应的安装包2建议下载 下载稳定版3解压到相应的目录，比如我是e盘 然后修改目录名字为nginx4进入nginx目录 双击nginx.exe 来启动nginx5此时 直接在浏览器地址栏输入：localhost 便能看到 欢迎页面，说明你虚拟主机已经搭建好了6但是有时候 我们需要配置路径 在默认情况下 他的root是 nginx目录下的html文件夹如若修改 则打开conf目录下的nginx.conf7找到server 选项 修改咯location 中的root 选项。8比如我修改到D：/webroot则修改为

nginx index指令

CentOS定位、查找文件的命令

定位、查找文件的命令

which 从path中找出文件的位置 find 找出所有符合要求的文件

whereis 找出特定程序的路径 locate　　 从索引中找出文件位置

1.which命令

语法：

which command

说明：

which命令的作用是，在PATH变量指定的路径中，搜索某个系统命令的位置，并且返回第一个搜索结果。在找到第一个符合条件的程序文件时，就立刻停止搜索，省略其余未搜索目录。也就是说，使用which命令，就可以看到某个系统命令是否存在，以及执行的到底是哪一个位置的命令。

实例：

[root@localhost /]# which ls

alias ls='ls --color=auto'

/bin/ls

[root@localhost /]# which nginx

/usr/bin/nginx

2.whereis命令

语法：

whereis [option] name

说明：

找出特定程序的可执行文件、源代码文件以及manpage的路径。你所提供的name会被先除去前置的路径以及任何.ext形式的扩展名。

whereis 只会在标准的Linux目录中进行搜索。

常用选项

-b

只搜索可执行文件。

-m

只搜索manpage。

-s

只搜索源代码文件。

-B directory

更改或限定搜索可执行的文件的目录。

-M directory

更改或限定搜索manpage的目录。

-S directory

更改或限定搜索源代码文件的目录。

实例：

[root@localhost /]# whereis grep

grep: /bin/grep /usr/share/man/man1p/grep.1p.gz /usr/share/man/man1/grep.1.gz

[root@localhost /]# whereis -b nginx

nginx: /usr/bin/nginx /usr/local/nginx

3.find命令

语法：

find paths expression [action]

说明：

以paths为搜索起点逐层往下找出每一个符合expression条件的文件，并对该文件执行action所代表的动作。expression是搜索条件，它由一个代表匹配项目的选项以及一个代表匹配模式的参数构成。

$ find <指定目录> <指定条件> <指定动作>

　　- <指定目录>： 所要搜索的目录及其所有子目录。默认为当前目录。

　　- <指定条件>： 所要搜索的文件的特征。

　　- <指定动作>： 对搜索结果进行特定的处理。

如果什么参数也不加，find默认搜索当前目录及其子目录，并且不过滤任何结果（也就是返回所有文件），将它们全都显示在屏幕上。

action是处理动作，它有一个代表“处理方式”的选项以及一个操作参数构成。若不指定action，则默认动作是显示出文件名。

常用的搜索条件

-name pattern 

-path pattern  

-lname pattern

找出名称、路径名称或符号链接的目标匹配pattern模式的文件。pattern可以包含shell的文件名通配符，路径是相对于搜索起点的。

常见处理动作

-print

显示出文件的相对路径（相对于搜索起点）。

-exec cmd /;

执行指定的shell命令。若cmd含有任何shell特殊字符，则他们之前都必须加上/符号，以免shell立刻执行他们。在cmd里，可以用”{}”符号(包括双引号)表示find所找出的文件。

1.按照文件名查找

　　　　(1)find / -name httpd.conf　　#在根目录下查找文件httpd.conf，表示在整个硬盘查找

　　　　(2)find /etc -name httpd.conf　　#在/etc目录下文件httpd.conf

　　　　(3)find /etc -name '*srm*'　　#使用通配符*(0或者任意多个)。表示在/etc目录下查找文件名中含有字符串‘srm’的文件

　　　　(4)find . -name 'srm*' 　　#表示当前目录下查找文件名开头是字符串‘srm’的文件

　　　　2.按照文件特征查找 　　　　

　　　　(1)find / -amin -10 　　# 查找在系统中最后10分钟访问的文件(access time)

　　　　(2)find / -atime -2　　 # 查找在系统中最后48小时访问的文件

　　　　(3)find / -empty 　　# 查找在系统中为空的文件或者文件夹

　　　　(4)find / -group cat 　　# 查找在系统中属于 group为cat的文件

　　　　(5)find / -mmin -5 　　# 查找在系统中最后5分钟里修改过的文件(modify time)

　　　　(6)find / -mtime -1 　　#查找在系统中最后24小时里修改过的文件

　　　　(7)find / -user fred 　　#查找在系统中属于fred这个用户的文件

　　　　(8)find / -size +10000c　　#查找出大于10000000字节的文件(c:字节，w:双字，k:KB，M:MB，G:GB)

　　　　(9)find / -size -1000k 　　#查找出小于1000KB的文件

　　　　3.使用混合查找方式查找文件

　　　　参数有： ！，-and(-a)，-or(-o)。

　　　　(1)find /tmp -size +10000c -and -mtime +2 　　#在/tmp目录下查找大于10000字节并在最后2分钟内修改的文件

   　　    (2)find / -user fred -or -user george 　　#在/目录下查找用户是fred或者george的文件文件

   　　    (3)find /tmp ! -user panda　　#在/tmp目录中查找所有不属于panda用户的文件

实例：

[root@localhost /]# find / -name nginx.conf

/www/server/nginx/conf/nginx.conf

/www/server/nginx/src/conf/nginx.conf

[root@localhost /]# find /www/server/nginx/conf -name nginx.conf

/www/server/nginx/conf/nginx.conf

4.locate命令

语法：locate patterns

说明：

locate命令其实是“find -name”的另一种写法，但是要比后者快得多，原因在于它不搜索具体目录，而是搜索一个数据库（/var/lib/locatedb），这个数据库中含有本地所有文件信息。Linux系统自动创建这个数据库，并且每天自动更新一次，所以使用locate命令查不到最新变动过的文件。为了避免这种情况，可以在使用locate之前，先使用updatedb命令，手动更新数据库。

实例：

[root@localhost /]# locate nginx.conf

/www/server/nginx/conf/nginx.conf

/www/server/nginx/conf/nginx.conf.default

/www/server/nginx/src/conf/nginx.conf

5.type命令

说明：

type命令其实不能算查找命令，它是用来区分某个命令到底是由shell自带的，还是由shell外部的独立二进制文件提供的。如果一个命令是外部命令，那么使用-p参数，会显示该命令的路径，相当于which命令。

实例：

[root@localhost /]# type cd

cd is a shell builtin

[root@localhost /]# type ls

ls is aliased to `ls --color=auto'

[root@localhost /]# type grep

grep is /bin/grep

cd是shell的自带命令（build-in）

grep是一个外部命令，并显示该命令的路径。

[root@localhost /]# type -p grep

/bin/grep

加上-p参数后，就相当于which命令。

nginx index on

第一种：Nginx自己的错误页面

Nginx访问一个静态的html 页面，当这个页面没有的时候，Nginx抛出404，那么如何返回给客户端404呢？

看下面的配置，这种情况下不需要修改任何参数，就能实现这个功能。

server {

listen 80;

server_name www.test.com;

root /var/www/test;

index index.html index.htm;

location / {

}

# 定义错误页面码，如果出现相应的错误页面码，转发到那里。

error_page 404 403 500 502 503 504 /404.html;

# 承接上面的location。

location = /404.html {

# 放错误页面的目录路径。

root /usr/share/nginx/html;

}

}

第二种：反向代理的错误页面

如果后台Tomcat处理报错抛出404，想把这个状态叫Nginx反馈给客户端或者重定向到某个连接，配置如下：

upstream www {

server 192.168.1.201:7777 weight=20 max_fails=2 fail_timeout=30s;

ip_hash;

}

server {

listen 80;

server_name www.test.com;

root /var/www/test;

index index.html index.htm;

location / {

if ($request_uri ~* ‘^/$’) {

rewrite .* http://www.test.com/index.html redirect;

}

# 关键参数：这个变量开启后，我们才能自定义错误页面，当后端返回404，nginx拦截错误定义错误页面

proxy_intercept_errors on;

proxy_pass http://www;

proxy_set_header HOST $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-FOR $proxy_add_x_forwarded_for;

}

error_page 404 /404.html;

location = /404.html {

root /usr/share/nginx/html;

}

}

第三种：Nginx解析php代码的错误页面

如果后端是php解析的，需要加一个变量

在http段中加一个变量

fastcgi_intercept_errors on就可以了。

指定一个错误页面：

error_page 404 /404.html;

location = /404.html {

root /usr/share/nginx/html;

}

指定一个url地址：

error_page 404 /404.html;

error_page 404 = http://www.test.com/error.html;