精华内容
下载资源
问答
  • - 我们都看过有些文章中的图片,你点击一下就会跳转到其他页面,可能会提示“404”或者“403”之类的,这说明文章的图片盗用了别的网站的图片,文章只是嵌入了一个链接,而图片所在的网站采用防盗链技术。...

    - 我们都看过有些文章中的图片,你点击一下就会跳转到其他页面,可能会提示“404”或者“403”之类的,这说明文章的图片盗用了别的网站的图片,文章只是嵌入了一个链接,而图片所在的网站采用防盗链技术。防盗链技术可以降低的服务器不必要的负载,以及版权之类的,当然,如果你的服务器群足够强大,你可以设置水印、品牌之类的标识。

    - 下面,我们来配置下nginx的防盗链:

    ## 1、nginx配置

    cd /etc/nginx/conf.d

    407d45eabd13418f61451dacc9ec48fc.png
    vi https.www.flighting.top.conf
    # HTTPS redirect
    server {
    	listen 443 ssl;
    
    	server_name www.flighting.top;
    
    	# SSL
    	ssl_certificate /etc/nginx/crt/test.crt;
    	ssl_certificate_key /etc/nginx/crt/test.key;
    
    	# security
    	#include conf.d/include/security.conf;
    
    	# logging
    	access_log /var/log/nginx/access.log;
    	error_log /var/log/nginx/error.log warn;
    
    	# reverse proxy
    	location / {
    		proxy_pass http://tomcat;
    		#include conf.d/include/proxy.conf;
    	}
    	
    	location ~* ^.+.(jpg|gif|png|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar)$ {
    		valid_referers none blocked  www.flighting.top;
    		if ($invalid_referer) {
    			#return 302  http://www.flighting.top/img/nolink.jpg;
    			return 404;
    			break;
    		}
    		access_log off;
    	}
    
    	# additional config
    	#include conf.d/include/general.conf;
    		
       # location / {
       #     root   /usr/share/nginx/html;
       #     index  index.html index.htm;
       # }
    }

    -就是基础之上加入下面配置:

    location ~* ^.+.(jpg|gif|png|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar)$ {
    		valid_referers none blocked  www.flighting.top;
    		if ($invalid_referer) {
    			#return 302  http://www.flighting.top/img/nolink.jpg;
    			return 404;
    			break;
    		}
    		access_log off;
    	}

    - location ~* ^.+.(jpg|gif|png|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar)$:匹配以 jpg/png/gif 结尾的文件请求

    - valid_referers: 指令用于设置允许访问资源的网站列表 (即白名单)

    - none : 匹配没有 Referer 的 HTTP 请求,如 valid_referers none

    - blocked: 匹配 HTTP 请求中含有 Referer ,但是被防火墙或者代理服务器修改,去掉了

    - 当请求的 refer 是合法的,即可以被后面任一参数所匹配, $invalid_referer 的值为0, 若不匹配则值为 1,即不合法的请求,直接返回 404

    - access_log off:不记录日志

    ## 2、测试

    - 我们来访问https://47.101.201.179,还是上次测试的页面:

    d57b43f452f9c484bc188ce36cd4092d.png

    - 找到一张图片:tomcat.png,在https://47.101.201.179访问是正常的

    397d0dc619db1cbee6000c1692ef8348.png

    - 我们来直接访问https://47.101.201.179/tomcat.png

    9a5efa6532bf91cb3e3a69a103746a88.png

    - 返回404,说明防盗链设置成功了

    展开全文
  • 安装先安装前提库yum -y install gcc gcc-c++ make libtool zlib zlib-devel openssl openssl-devel pcre pcre-devel下载安装包:http://nginx.org/en/download.html解压缩后,进入文件夹中执行:./configure再执行...

    安装

    先安装前提库

    yum -y install gcc gcc-c++ make libtool zlib zlib-devel openssl openssl-devel pcre pcre-devel

    下载安装包:http://nginx.org/en/download.html

    解压缩后,进入文件夹中执行:./configure

    再执行: make & make install

    配置文件

    #user  nobody;
    worker_processes  1;
    
    #error_log  logs/error.log;
    #error_log  logs/error.log  notice;
    #error_log  logs/error.log  info;
    
    #pid        logs/nginx.pid;
    
    events {
        worker_connections  1024;
    }
    
    http {
        include       mime.types;
        default_type  application/octet-stream;
    
        #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
        #                  '$status $body_bytes_sent "$http_referer" '
        #                  '"$http_user_agent" "$http_x_forwarded_for"';
    
        #access_log  logs/access.log  main;
    
        sendfile        on;
        #tcp_nopush     on;
    
        #keepalive_timeout  0;
        keepalive_timeout  65;
    
        #gzip  on;
    
        server {
            listen       81;
            server_name  127.0.0.1;
    
            #charset koi8-r;
    
            #access_log  logs/host.access.log  main;
    
            location / {
                root   /usr/local/YOURFOLDER;
                index  index.html index.htm;
            }
    
            location ~ .*.(gif|jpg|jpeg|bmp|png|ico|txt|js|css)$   
            {   
                root /usr/local/ems_webfront;   
                expires      7d; 
            }
    
            #error_page  404              /404.html;
    
            # redirect server error pages to the static page /50x.html
            #
            error_page   500 502 503 504  /50x.html;
            location = /50x.html {
                root   html;
            }
    
            # proxy the PHP scripts to Apache listening on 127.0.0.1:80
            #
            #location ~ .php$ {
            #    proxy_pass   http://127.0.0.1;
            #}
    
            # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
            #
            #location ~ .php$ {
            #    root           html;
            #    fastcgi_pass   127.0.0.1:9000;
            #    fastcgi_index  index.php;
            #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
            #    include        fastcgi_params;
            #}
    
            # deny access to .htaccess files, if Apache's document root
            # concurs with nginx's one
            #
            #location ~ /.ht {
            #    deny  all;
            #}
        }
    
    
        # another virtual host using mix of IP-, name-, and port-based configuration
        #
        #server {
        #    listen       8000;
        #    listen       somename:8080;
        #    server_name  somename  alias  another.alias;
    
        #    location / {
        #        root   html;
        #        index  index.html index.htm;
        #    }
        #}
    
    
        # HTTPS server
        #
        #server {
        #    listen       443 ssl;
        #    server_name  localhost;
    
        #    ssl_certificate      cert.pem;
        #    ssl_certificate_key  cert.key;
    
        #    ssl_session_cache    shared:SSL:1m;
        #    ssl_session_timeout  5m;
    
        #    ssl_ciphers  HIGH:!aNULL:!MD5;
        #    ssl_prefer_server_ciphers  on;
    
        #    location / {
        #        root   html;
        #        index  index.html index.htm;
        #    }
        #}
    
    }

    运行

     ./nginx

    停止运行

    ./nginx -s stop

    try_files解决刷新404的问题

    location / {
                root   /mydata/transfer/html/helper/dist;
                index  index.html index.htm;
                try_files  $uri $uri/ /index.html;
            }

    在配置中加上try_files,意思跟翻译差不多,“尝试读取文件”。

    uri这个是nginx的一个变量,存放着用户访问的地址,例如http://localhost:8200/chooseSize那么uri就是/chooseSize;uri/代表访问的是一个目录例如http://localhost:8200/chooseSize/那么就是/chooseSize/;最后/index.html就是我们首页的地址。

    最终上面的意思是:

    1. 如果第一个存在,直接返回;
    2. 不存在的话读取第二个,如果存在,读取返回;
    3. 如果还是不存在,就会fall back到 try_files 的最后一个选项 /index.html,发起一个内部 “子请求”,也就是相当于 nginx 发起一个 HTTP 请求到 http://localhost:8200/index.html,再通过前端路由到/chooseSize。
    展开全文
  • 这就不正常了,于是手工访问了一下一个不存在的页面,虽然 站点 在前台给我展示了一个 404 页面,但是浏览器显示返回码确实是 200!!纳尼?还以为站点更新后改了这个机制呢,把主题下的 404.php 加了一个强行的 404...
    3146c2a9be5632e9e0e45d501b65ed01.png

    看日志的时候,我发现有大量请求到了站点其实并不存在的地址,但是返回码居然是 200??这就不正常了,于是手工访问了一下一个不存在的页面,虽然 站点 在前台给我展示了一个 404 页面,但是浏览器显示返回码确实是 200!!纳尼?

    还以为站点更新后改了这个机制呢,把主题下的 404.php 加了一个强行的 404 返回码,发现没有任何效果。

    最后发现,居然是自己以前把 404 页面静态化留下的坑!

    原因很简单,当时经常有人攻击一些不存在的页面,也就是每次都是动态的 404,服务器自然就容易高负载,因此做了一个静态化处理:

    通过 curl 请求一个不存在的地址,触发 404 返回内容,然后保存在网站的某个目录下,比如 xxxx 下面

    curl -o /data/wwwroot/web/xxxx/404.html https://xx.com/404/404

    然后,在 Nginx Vhost 下新增 404 响应规则:

    error_page 404=/xxxx/404.html;

    重启 Nginx 之后,再访问不存在的博客页面的时候,Nginx 就直接返回 404.html 的内容了,从而实现 404 页面的静态化。

    但是,Nginx 这里我写错了,导致每次返回 404.html 都是 200 返回码!!这样其实会误导搜索引擎的判断,以为页面是存在的。。。。大坑。

    正确的 Nginx 配置方法应该是:

    error_page 404 /xxxx/404.html;

    也就是不用等号,而是用空格!修改后,重启 Nginx,然后访问不存在的地址发现已经是 404 返回码了,问题解决!

    展开全文
  • 背景基于Springboot应用以war包的形式运行在tomcat容器中,当更新war包时会有一段时间服务返回404,这对于线上服务是不可接受的。4层的负载均衡可以自动将80端口关闭的节点下线,但由于内网服务器位于堡垒机后方,...

    背景

    基于Springboot应用以war包的形式运行在tomcat容器中,当更新war包时会有一段时间服务返回404,这对于线上服务是不可接受的。4层的负载均衡可以自动将80端口关闭的节点下线,但由于内网服务器位于堡垒机后方,根据公司规定不能自行配置SSH服务,所以无法执行远程脚本。所以只能通过别的方式实现。

    实验素材

    8011d29f95b02889153bde25f5828fc4.png
    1. nginx 作为web server和7层负载均衡
    2. tomcat * 2 作为应用后端
    3. gitlab-ce 代码版本控制
    4. jenkins 发布平台

    基本原理

    基本的原理就是让Nginx后方有3个Tomcat容器,其中1个是active,1个是standby,正常情况下不会访问到standby的容器,但可以通过额外的手段保证standby的容器是可以提供服务的,在发布前先更新所有的standby节点,验证没问题之后更新active的容器,来保证服务不会中断。

    实际操作

    创建springboot项目

    参考Springboot使用内置和独立tomcat以及其他思考。

    编写同一个接口的不同版本

    // tag v1
    @RestControllerpublic class HelloController {    @GetMapping("/hello")
        public String hello() {        return "V1";
        }}
    // tag v2
    @RestControllerpublic class HelloController {    @GetMapping("/hello")
        public String hello() {        return "V2";
        }}

    打包

    mvn clean package -Dmaven.test.skip=true

    创建两个tomcat容器

    docker run -itd --name tomcat-active -v /tmp/tomcat/active:/usr/local/tomcat/webapps -p 32771:8080 tomcat
    docker run -itd --name tomcat-standby -v /tmp/tomcat/standby:/usr/local/tomcat/webapps -p 32772:8080 tomcat

    将war包拷贝到容器中

    可能是docker toolbox的问题,无法挂载目录,所以只好把war包手动拷贝进去。

    docker cp ~/workspace/spring-demo/target/spring-demo-0.0.1-SNAPSHOT.war tomcat-active:/usr/local/tomcat/webapps/
    docker cp ~/workspace/spring-demo/target/spring-demo-0.0.1-SNAPSHOT.war tomcat-standby:/usr/local/tomcat/webapps/
    

    访问两个容器中的服务

    稍等片刻两个容器中的服务会自动部署,就可以分别通过相应的端口访问了,简单压测一下QPS可以达到2000+且没有报错。

    $ wrk -c 20 -d 10 -t 4 http://192.168.99.100:32771/spring-demo-0.0.1-SNAPSHOT/hello
    Running 10s test @ http://192.168.99.100:32771/spring-demo-0.0.1-SNAPSHOT/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency    10.20ms    8.70ms 122.66ms   81.20%
        Req/Sec   554.18    167.66     1.04k    63.25%
      22088 requests in 10.02s, 2.43MB read
    Requests/sec:   2203.76
    Transfer/sec:    247.89KB
    $ wrk -c 20 -d 10 -t 4 http://192.168.99.100:32772/spring-demo-0.0.1-SNAPSHOT/hello
    Running 10s test @ http://192.168.99.100:32772/spring-demo-0.0.1-SNAPSHOT/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency    11.30ms   14.24ms 186.52ms   92.95%
        Req/Sec   557.54    207.91     1.24k    67.17%
      22025 requests in 10.03s, 2.42MB read
    Requests/sec:   2196.36
    Transfer/sec:    247.05KB

    配置Nginx

    upstream ha {
        server 192.168.99.100:32771;
        server 192.168.99.100:32772 backup;
    }server {
        listen       80;
        server_name  _;
        location / {
            proxy_next_upstream http_502 http_504 http_404 error timeout invalid_header;
            proxy_pass   http://ha/spring-demo-0.0.1-SNAPSHOT/;
        }}

    注意:默认情况下只会转发GET/HEAD/PUT/DELETE/OPTIONS这种幂等的请求,而不会转发POST请求,如果需要对POST请求也做转发,就需要加上non_idempotent配置,整体配置如下

    upstream ha {
        server 192.168.99.100:32771;
        server 192.168.99.100:32772 backup;
    }server {
        listen       80;
        server_name  _;
        location / {
            proxy_next_upstream http_502 http_504 http_404 error timeout invalid_header non_idempotent;
            proxy_pass   http://ha/spring-demo-0.0.1-SNAPSHOT/;
        }}

    注意proxy_next_upstream http_502 http_504 http_404 error timeout invalid_header;这行,这里就是表示把访问当前的upstream返回了这些状态码的请求转发到upstream中的下一台机器,在我们现在的应用场景下,当war包发布时,正在更新war包的tomcat会返回404,也就是对应http_404,如果不配置这行,是不会做转发的。

    但这样简单的配置还会有一个问题,那就是Nginx不会把出问题的后端从upstream中摘除,也就是说请求还会访问到这个正在更新中的realserver,只是Nginx会再把请求转发到下一台好的realserver上,这样会增加一些耗时。目前有三种方式可以实现对Nginx负载均衡的后端节点服务器进行健康检查,具体参考Nginx负载均衡

    通过Nginx压测

    基本测试

    1. 两个tomcat节点均正常的情况下压测
    $ wrk -c 20 -d 10 -t 4 http://192.168.99.100:32778/hello
    Running 10s test @ http://192.168.99.100:32778/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency    57.36ms   32.06ms 335.36ms   71.29%
        Req/Sec    89.29     48.20   390.00     85.25%
      3577 requests in 10.05s, 562.30KB read
    Requests/sec:    355.77
    Transfer/sec:     55.93KB

    和上面没有经过Nginx的压测相比,最明显的变化就是QPS下降了84%,平均响应时间增加了5倍,猜测可能是因为Nginx使用的默认配置中worker_processes 1;的问题。

    1. 在开始压测后立即删除tomcat-active容器中的war包和目录,结果如下
    $ wrk -c 20 -d 10 -t 4 http://192.168.99.100:32778/hello
    Running 10s test @ http://192.168.99.100:32778/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency    57.29ms   28.69ms 181.88ms   67.38%
        Req/Sec    87.93     39.51   240.00     75.25%
      3521 requests in 10.05s, 553.50KB read
    Requests/sec:    350.22
    Transfer/sec:     55.05KB

    同样没有非200的响应,而且整体和正常情况相当。

    1. 只有standby节点工作的情况下压测
    $ wrk -c 20 -d 10 -t 4 http://192.168.99.100:32778/hello
    Running 10s test @ http://192.168.99.100:32778/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency    72.12ms   35.99ms 240.89ms   68.34%
        Req/Sec    70.04     31.84   180.00     76.50%
      2810 requests in 10.05s, 441.71KB read
    Requests/sec:    279.48
    Transfer/sec:     43.93KB

    可以看到,响应时间有明显的增加,QPS也有明显的下降,也验证了上面说的响应是404的请求会被转发到正常工作的节点,但有问题的节点不会被摘除导致的响应时间变长的问题。

    进一步测试

    为了消除上面测试中可能存在war包删除后对服务的影响还没有生效,压测就已经结束的可能,将压测时间调长,增加至60s。

    1. 两个节点都正常的情况
    $ wrk -c 20 -d 60 -t 4 http://192.168.99.100:32778/hello
    Running 1m test @ http://192.168.99.100:32778/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency    55.53ms   28.10ms 306.58ms   70.07%
        Req/Sec    91.52     39.35   300.00     69.23%
      21906 requests in 1.00m, 3.36MB read
    Requests/sec:    364.66
    Transfer/sec:     57.32KB

    整体情况和上面10s的测试相同。查看日志发现backup节点没有接收到任何请求。为了验证是否是worker_processes配置导致的,把这个值改成4之后重新测试,结果如下

    $ wrk -c 20 -d 60 -t 4 http://192.168.99.100:32778/hello
    Running 1m test @ http://192.168.99.100:32778/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency    41.55ms   24.92ms 227.15ms   72.21%
        Req/Sec   125.06     46.88   373.00     71.76%
      29922 requests in 1.00m, 4.59MB read
    Requests/sec:    498.11
    Transfer/sec:     78.29KB

    可以看到,有了将近20%的提升,但还是不太符合预期。

    1. 开始测试后立即更新active节点的war包
    $ wrk -c 20 -d 60 -t 4 http://192.168.99.100:32778/hello
    Running 1m test @ http://192.168.99.100:32778/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency    54.40ms   33.76ms 329.73ms   70.53%
        Req/Sec    95.85     56.28   420.00     81.60%
      22914 requests in 1.00m, 3.52MB read
    Requests/sec:    381.42
    Transfer/sec:     59.95KB

    没有明显变化,测试开始后有一段时间standby节点收到请求,后面请求又全部指向了active节点。可能是因为服务太简单,重新加载的太快,只有很少量(5750)的请求转发到了standby节点,所以对整体结果影响不大。 3. 开始测试后立即删除active节点的war包

    $ wrk -c 20 -d 60 -t 4 http://192.168.99.100:32778/hello
    Running 1m test @ http://192.168.99.100:32778/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency    72.11ms   34.33ms 346.24ms   69.54%
        Req/Sec    70.16     29.78   191.00     67.23%
      16813 requests in 1.00m, 2.58MB read
    Requests/sec:    279.84
    Transfer/sec:     43.99KB

    删除节点后,所有的请求都会先请求active,然后被Nginx转发至standby,所以吞吐量有明显下降,延迟也有明显的提升。

    效果测试

    1. 直接访问active
    $ wrk -c 20 -d 60 -t 4 http://10.75.1.42:28080/web-0.0.1-SNAPSHOT/hello
    Running 1m test @ http://10.75.1.42:28080/web-0.0.1-SNAPSHOT/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency     5.56ms   25.16ms 203.83ms   95.82%
        Req/Sec     7.54k     0.91k    8.31k    84.44%
      1803421 requests in 1.00m, 217.03MB read
    Requests/sec:  30006.18
    Transfer/sec:      3.61MB

    服务器的性能果然还是比本地强太多。

    1. 在进行性能压测期间发布新版本
    $ wrk -c 20 -d 60 -t 4 http://10.75.1.42:28080/web-0.0.1-SNAPSHOT/hello
    Running 1m test @ http://10.75.1.42:28080/web-0.0.1-SNAPSHOT/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency     4.47ms   22.31ms 401.95ms   96.67%
        Req/Sec     7.58k     0.88k    8.26k    87.12%
      1811240 requests in 1.00m, 285.84MB read
      Non-2xx or 3xx responses: 72742
    Requests/sec:  30181.93
    Transfer/sec:      4.76MB

    发布新版本导致4%的请求失败。

    1. 通过Nginx访问服务
    $ wrk -c 20 -d 60 -t 4 http://10.75.1.42:28010/web/hello
    Running 1m test @ http://10.75.1.42:28010/web/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency     2.94ms   16.21ms 248.18ms   98.01%
        Req/Sec     6.02k   551.52     6.92k    83.38%
      1437098 requests in 1.00m, 260.33MB read
    Requests/sec:  23948.20
    Transfer/sec:      4.34MB

    虽然服务器配置的worker_processes auto,实际上开了40个进程,但仍然达不到直接访问Java服务的吞吐量。

    1. 通过Nginx压测期间发布新版本
    $ wrk -c 20 -d 60 -t 4 http://10.75.1.42:28010/web/hello
    Running 1m test @ http://10.75.1.42:28010/web/hello
      4 threads and 20 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency     4.09ms   20.50ms 402.11ms   97.12%
        Req/Sec     5.89k   733.62     6.86k    84.85%
      1404463 requests in 1.00m, 253.67MB read
    Requests/sec:  23401.54
    Transfer/sec:      4.23MB

    可以看到,延迟明显变大了,但总体的QPS没有明显下降,还是因为存在一些转发。

    思考

    原来是一台机器上运行一个tomcat容器,现在要运行两个,那么会对机器的负载造成多大的影响呢?可以通过visualvm连接上远程tomcat来观察对内存和CPU的占用

    de3f929f72a964a2ac99ace0f9264be7.png

    7cbe24d596bef81319b83645b7b0eaac.png

    可以看到正常情况下,backup容器对服务器的负载基本可以忽略不计。即便是在发布期间,backup容器也只是在active容器重新载入期间承担职责,之后马上就恢复了。

    b50dccc642d4b0da34cdc403b839b8c5.png

    f5c9800fb2914d423303ad213da1e132.png

    新版本在线上正式运行之后为保证下一次发布新版本时backup版本是最新的,需要再发布一下backup版本,当然这时流量都在active节点上,对backup节点的发布更新操作不会对负载有什么影响。

    7f21238050decac4a61a077b22e73cea.png

    总结

    可以通过Nginx的backup机制可以保证服务不中断的情况下发布新版本。总体的发布流程如下:

    1. 发布新版本到active容器
    2. 确认发布的新版本稳定后发布新版本到backup容器

    优势

    1. 任意一台机器上在任意时刻都保证有一个tomcat容器是可用的,保证服务不中断
    2. 从直观上的分机器上线改为直接全量上线,并且保证如果上线的新版本有问题时也不会影响线上服务

    劣势

    1. 需要上线两次
    2. 需要在tomcat容器所在的机器上安装Nginx和作为backup的tomcat的容器
    3. backup容器在“待机”时的消耗


    链接:https://juejin.im/post/6867088509245603854
    来源:掘金

    展开全文
  • Nginx定义404页面并返回404状态码, WebServer是nginx,直接告诉我应该他们配置了nginx的404错误页面,虽然请求不存在的资源可以成功返回404页面,但返回状态码确是200。 404.html 内容为sorry docker 。。。. ...
  • 404是请求页面不存在的错误代码,在Nginx中有时处理jQuery中的ajax方法虽然能返回404页面但错误代码却返回200,针对此问题我们具体来看一下Nginx中404页面的配置及AJAX请求返回404页面的方法
  • 什么是404页面如果碰巧网站出了问题,或者用户试图访问一个并不存在的页面时,此时服务器会返回代码为404的错误信息,此时对应页面就是404页面。404页面的默认内容和具体的服务器有关。如果后台用的是NGINX服务器,...
  • 更改nginx服务器404返回页面

    千次阅读 2018-06-14 15:49:56
    后台Tomcat处理报错抛出404,想把这个状态叫Nginx反馈给客户端或者重定向到某个连接。我们公司刚遇到的情况。解决方法如图:1.创建自己的404.html页面 2.更改nginx.conf在http定义区域加入: fastcgi_intercept_...
  • 今天主要讲下Linux系统下Nginx配置404错误页面,网络上 也有不少的相关文章,不过返回的状态码是200(正常状态码)。搜索引擎抓取到错误页面的时候,发现返回的是200,他就认为这是一个正常请求并正常响应 的一个...
  • 找资料的时候发现网上全部是php返回的,去nginx官网看了下资料才发现:环境:nginx+tomcat nginx做反向代理tomcat,当url连接不存在时,nginx返回404方法: 在nginx配置文件nginx.conf中加入配置: proxy_intercept_...
  • nginx配置404

    2018-01-03 17:10:27
    如果碰巧网站出了问题,或者用户试图访问一个并不存在的页面时,此时服务器会返回代码为404的错误信息,此时对应页面就是404页面。404页面的默认内容和具体的服务器有关。如果后台用的是NGINX服务器,那么404页面的...
  • nginx设置404返回页面

    2013-12-14 10:20:12
    访问.shtml页面时不存在跳转到404页面,用<!--#include 包含的页面不存在时则显示空白     如果是.shtml的默认跳转到404.html页面 在配置文件里添加location 404相关配置   如果是Include包含的...
  • 404页面基础配置404错误是WWW网站访问容易出现的错误。最常见的出错提示:404 NOT FOUND。404错误页的设置对网站SEO有很大的影响,而设置不当,比如直接转跳主页等...当搜索引擎获得了一个错误链接时,网站应该返回4...
  • 主要介绍了Nginx中定义404页面并且返回404状态码的正确方法,本文在一次AJAX调用时发现了这个问题,服务器返回了一个404页页但没有返回404状态码,需要的朋友可以参考下
  • 为什么要返回404状态码,302不行吗?其实我觉得也是可以的,至于为什么不行,那咱们去问问李彦宏吧fastcgi_intercept_errorson; proxy_intercept_errorson; error_page404/404.html; location=/404.html{ root...
  • 最常见的出错提示:404 NOT FOUND。404错误页的设置对网站SEO有很大的影响,而设置不当,比如直接转跳主页等,会被搜索引擎降权拔毛。...当搜索引擎获得了一个错误链接时,网站应该返回404状态码,告诉搜...
  • nginx设置404页面跳转

    千次阅读 2018-03-09 11:07:25
    nginx设置404页面跳转目录1 nginx设置404错误指向页面2 制作一个404.html页面3 重启nginx使配置生效4 避免出现404错误5 roboot.txt屏蔽404页面6 nginx404页面进行301重定向如果网页的链接地址改变了,在通过这个...
  • nginx自己配置的404页面和laravel配置的404页面;如果报了404;执行laravel的404页面;那这个404页面对nginx来说意味着...根据你的nginx配置如果请求的是静态文件,那么nginx会去找,文件不存在时,nginx返回404...
  • 关于nginx返回默认404页面的查看

    千次阅读 2014-03-13 15:57:59
    一般新手都去 /usr/local/nginx/html  这个目录下面找,以为html目录下面有 404.html 这个文件,其实不是,刚装完nginx是没有这个文件的,返回给浏览器的code是由nginx出来的,默认情况下下nginx有个自己定义的响应...
  • 修改你的nginx 配置文件server 模块404字段 http { ...... fastcgi_intercept_errors on; ...... } server { ....... error_page 404 /404.html; #这里404 后面和路径 之前不要用等号。用空格分隔,否则看...
  • codeigniter在nginx返回404 not found

    千次阅读 2015-01-03 15:24:49
    难免有些生疏,就把codeigniter转移到了,顺便在温习下linux下的操作,l跟window下的环境略有差别,linux下的环境是lnmp,但是谁曾想还没开始就遇到了问题,打开对应的url居然返回nginx404,难道是我的url拼错了...
  • Nginx指定404页面的方法: ...nginx访问一个静态的html 页面,当这个页面没有的时候,nginx抛出404,那么如何返回给客户端404呢?看下面的代码 这种情况下不需要修改任何参数,就能实现这个功能。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 570
精华内容 228
关键字:

nginx返回404