阿里云CDN开启https加速后出现502无法访问原因

最近准备给博客上CDN,因为博客本身是部署在阿里的ESC上,于是选择了阿里的CDN服务。因为博客已经全站Https了,所以在配置CDN的时候也选择了上传证书,进行了各种配置。只是当配置完成后,发现域名无法访问,网站打不开了。

当时选择的加速的域名是 www.shangyexin.com ,源站是ESC的IP,配置的回源host是加速域名。

这里解释一下几个概念,摘自阿里云官方文档。
源站: 源站决定了回源时,请求到哪个IP
回源host:回源host决定回源请求访问到该IP上的哪个站点

例子1:源站是域名
源站为 www.a.com 回源host为 www.b.com
那么实际回源是请求到 www.a.com 解析到的IP,对应的主机上的站点 www.b.com

例子2:源站是IP
源站为1.1.1.1 回源host为www.b.com
那么实际回源的是1.1.1.1对应的主机上的 站点www.b.com

自定义在CDN节点回源时所需访问的具体域名(如果您一个IP源站绑定了多个域名/站点的时候,就需设置回源Host 指定回到具体哪个域名,否则会回源失败)。
– 回源host 为可选配置项,默认值为:
– 如果源站是 IP类型,回源host默认加速域名。
– 如果源站是 OSS源站类型,回源host默认是源站域名。
– 可选项分别是:加速域名、源站域名、自定义域名。

注意:目前不支持sni 回源。
别看最后一句不起眼的:目前不支持sni 回源。
我后面所有的折腾其实就是因为没有意识到这句话的含义,想着这个应该和我没关系。

好了,我们继续。
这里画了一个简单的流程图说明一下我对阿里这个配置的理解。
CDN流程:

对应名词在图中的位置:

这个流程用文字再说一遍就是,当我想要访问加速的域名 www.shangyexin.com 的时候,我们会被解析到设置的CNAME域名上,也就是阿里的CDN服务器上,加入这时候CDN服务器上没有我们想要的资源,这时候他会去我们的源站上取,但是怎么知道源站在哪呢?当然是我们配置的啦!这时候如果源站配置的是IP,嗯,好了,CDN服务器直奔这个IP;如果我们源站配置的是域名的话,嗯,这个也简单,先解析出这个域名的IP是啥,然后我们再直奔这个IP。就这样,CDN服务器找到了源站所在服务器的IP,但是,这时候问题又来了,假如这个IP上有不止一个域名,服务器如何知道你想要哪个域名的资源呢?当然你CDN服务器去取时就要告诉这个它,我要的是 www.shangyexin.com 这个域名的资源,这就是是回源host的意义。

至于源站端口设置,就是告诉CDN服务器,你从80还是443端口来取数据,一般http对应80端口,https对应443端口。

而https设置决定了CDN服务器和用户之间是用http还是https进行数据传输,如果不设置的默认用http,设置的话就是https。

所以回到最初的起点,我本来的初衷就是阿里云CDN开启https加速。而且用户和CDN服务器之间的交互是阿里的事,我也上传了证书,所以问题肯定是出在了CDN服务器和源站交互之间。
因为我无论是通过80还是443端口访问源站,均会失败!查找问题的原因很辛苦,耗费了我很多时间,防火墙啊各种等等,这里暂且不表。我只想说最后的原因。
这里的原因还不一样。

通过80端口访问失败的原因是:

wordpress设置了全站https,所有http访问会进行301跳转。

所以CDN服务器没办法通过80端口获取到源站的数据。

通过443端口访问失败的原因是:

目前不支持sni 回源。

是的,就是前面那个不起眼的注意。

究竟为何导致服务器屡屡访问失败,是人性的扭曲?还是道德的沦丧?欢迎收看今天的《走近科学》之SNI。

下面一段摘自网络:

早期的SSLv2根据经典的公钥基础设施PKI(Public Key Infrastructure)设计,它默认认为:一台服务器(或者说一个IP)只会提供一个服务,所以在SSL握手时,服务器端可以确信客户端申请的是哪张证书。
但是让人万万没有想到的是,虚拟主机大力发展起来了,这就造成了一个IP会对应多个域名的情况。解决办法有一些,例如申请泛域名证书,对所有*.yourdomain.com的域名都可以认证,但如果你还有一个yourdomain.net的域名,那就不行了。
在HTTP协议中,请求的域名作为主机头(Host)放在HTTP Header中,所以服务器端知道应该把请求引向哪个域名,但是早期的SSL做不到这一点,因为在SSL握手的过程中,根本不会有Host的信息,所以服务器端通常返回的是配置中的第一个可beian用证书。因而一些较老的环境,可能会产生多域名分别配好了证书,但返回的始终是同一个。
既然问题的原因是在SSL握手时缺少主机头信息,那么补上就是了。
SNI(Server Name Indication)定义在RFC 4366,是一项用于改善SSL/TLS的技术,在SSLv3/TLSv1中被启用。它允许客户端在发起SSL握手请求时(具体说来,是客户端发出SSL请求中的ClientHello阶段),就提交请求的Host信息,使得服务器能够切换到正确的域并返回相应的证书。

所以CDN服务器访问源站时,因为没有不支持SNI,而我的服务器也正好是通过LANMP配置的,上面跑了不止一个域名,而且另外几个域名也配置了https,导致CDN服务器一直无法访问源站,取到想要的信息,所以就出现了开头的502错误。

最后我想说的是如果我想在阿里云CDN开启https加速,唯一可行的做法是CDN与源站直接采用http协议,且不说我本来就想实现全程https加密,而且如果这样配置的话,还需要将wordpress配置为同时支持http和https,颇为麻烦,所以只能就此作罢,因为暂时实在不想折腾了。
———————
作者:江山灬如画
来源:CSDN
原文:https://blog.csdn.net/shangyexin/article/details/80968234
版权声明:本文为博主原创文章,转载请附上博文链接!

go 代理服务器(cookie设置失败无法登录),nginx设置Domain

go 代理服务器(cookie设置失败无法登录),nginx设置Domain

复制代码
 1 Method POST
 2 URL https://vjudge.net/user/login
 3 Proto HTTP/1.1
 4 ProtoMajor 1
 5 ProtoMinor 1
 6 Header map[Referer:[http://127.0.0.1:8002/] Accept-Language:[zh-CN,zh;q=0.8] Connection:[keep-alive] Origin:[http://127.0.0.1:8002] Content-Type:[application/x-www-form-urlencoded; charset=UTF-8] X-Requested-With:[XMLHttpRequest] Accept-Encoding:[gzip, deflate, br] Cookie:[io=oiuZ1YssLxHIpLGMAAAo; _ga=GA1.1.1822669068.1495898591; _gid=GA1.1.2058057953.1495904201] Content-Length:[39] User-Agent:[Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36] Accept:[*/*]]
 7 Body &{0xc42011afe0 <nil> <nil> false true {0 0} false false false 0x6068c0}
 8 ContentLength 39
 9 TransferEncoding []
10 Close false
11 Host vjudge.net
12 Form map[]
13 PostForm 0x6114c0
14 MultipartForm <nil>
15 Trailer map[]
16 RemoteAddr 127.0.0.1:37558
17 RequestURI 
18 TLS <nil>
19 Cancel <nil>
20 Response <nil>
21 --------------------------------------------------------------
22 Status 200 OK
23 StatusCode 200
24 Proto HTTP/2.0
25 ProtoMajor 2
26 ProtoMinor 0
27 Header map[Server:[nginx/1.10.3] Date:[Sat, 27 May 2017 16:56:53 GMT] Content-Type:[text/plain;charset=ISO-8859-1] Content-Length:[7] Set-Cookie:[JSESSIONID=F55D0140082CA33C63F7A7C7B4C968B9; Domain=.vjudge.net; Path=/; HttpOnly Jax.Q=1406100039|89TFHFKYFR2DTH8AVLC2JRLIUTMJLE; Domain=.vjudge.net; Expires=Sun, 27-May-2018 16:56:53 GMT; Path=/] Access-Control-Allow-Origin:[http://127.0.0.1:8002] Vary:[Origin] Access-Control-Allow-Credentials:[true]]
28 Body {0xc420405a40}
29 ContentLength 7
30 TransferEncoding []
31 Close false
32 Uncompressed false
33 Trailer map[]
34 Request &{POST https://vjudge.net/user/login HTTP/1.1 1 1 map[Connection:[keep-alive] Origin:[http://127.0.0.1:8002] Content-Type:[application/x-www-form-urlencoded; charset=UTF-8] X-Requested-With:[XMLHttpRequest] Referer:[http://127.0.0.1:8002/] Accept-Language:[zh-CN,zh;q=0.8] Content-Length:[39] User-Agent:[Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36] Accept:[*/*] Accept-Encoding:[gzip, deflate, br] Cookie:[io=oiuZ1YssLxHIpLGMAAAo; _ga=GA1.1.1822669068.1495898591; _gid=GA1.1.2058057953.1495904201]] 0xc4200e6740 <nil> 39 [] false vjudge.net map[] map[] <nil> map[] 127.0.0.1:37558  <nil> <nil> <nil> 0xc4200e6780}
35 TLS &{771 true false 49200 h2 true  [0xc420152000 0xc420152480] [[0xc420152000 0xc420152480 0xc420252900]] [] [] [23 179 124 44 29 163 172 94 255 255 155 248]}
36 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
复制代码

设置cookie失败是因为Set-Cookie的Domain=.vjudge.net; 改为自己的域名“.gzhuacm.cn”或者”“空字符串就可以了,有这个的话浏览器会根据域名设置为指定域名的cookie

 

然后用nginx监听vjudge.gzhuacm.cn,转发到本地8002端口

如果用内网的话setsid autossh -CNg -L 9000:127.0.0.1:8002 root@gzhuacm.cn 将本地9000端口的访问转发到远程的8002端口处理(两层代理),访问内网的ip:9000 ,用两层代理是为了实现网上断网后也可以通过校园网访问oj

 

 

后面去nginx官网差了下,原来可以直接在nginx改,这样就不用go转发了

Syntax: proxy_cookie_domain off;
proxy_cookie_domain domain replacement;
Default:
proxy_cookie_domain off;
Context: httpserverlocation

然后改成proxy_cookie_domain .vjudge.net vj.gzhuacm.cn

Nginx 反向代理及 Cookie 相关问题

最近一个项目,遇到了Nginx反向代理和Cookie的问题,遇到的问题很杂,经过一周多逐步摸索,总算有个解决方案了,做个记号,主要是记录下遇到问题的过程,以便出现问题时备查。
【背景】

  1. 客户原有的使用Domino开发的Web应用系统,需要部分数据通过手机端展示;
  2. 原Domino系统只能通过内网访问,没有域名,内网的机器都需要修改hosts来解决域名问题;(至于为什么没有通过内网DNS进行域名解析设置,还不太清楚,不过这个对项目本身没有影响)

【问题及解决办法】

问题1:手机端需要从外网访问,没有域名,没有越狱或root的手机是不能修改hosts的,且Domino服务器必须通过域名访问。

解决方案:

  1. 增加一台服务器,安装Nginx作为反向代理,申请外网IP,并且通过PAT设置,通过外网访问到这台Nginx,Nginx负责将请求转发至目标服务器(Domino);
  2. 修改反向代理服务器的hosts,保证这台机器可以正常通过hosts中的域名访问Domino;
  3. 手机端可以通过IP访问反向代理即可,无需域名。
问题2:Domino中,链接中/符号引发的问题

由于Domino的技术特点,很多链接都是需要写上/的,如:src="/names.nsf?xxx",有的是页面中这样写的,也有的是通过302跳转时自动跳到这个位置,这一点与Java应用不同,Java应用中更多的是相对位置,不用写这个/。这个符号导致的问题如下:本来希望通过http://nginx_server/myapp/的方式来访问,将请求转发至http://domino_server/,这个需求可以通过在nginx.conf中这样设置解决:

location /myapp {
    proxy_pass http://domino_server/;
}

但是由于/的作用,导致直接访问到了http://nginx_server/,而不再通过/myapp,导致报页面内容找不到。
解决方案:
所以还需要在Nginx中,增加对/的反向代理:

location / {
    proxy_pass http://domino_server/;
}
问题3:认证问题

Domino服务器中,通过写了一些接口代码,提供RESTful的服务,来对手机端进行提供服务。但是由于原来的环境,没有SSO,而且不通过认证,没法访问到Domino里面的接口代码。
解决方案:
手机端通过HTTP,模拟登录过程

问题4:“问题3”的解决方案,由于经过了反向代理,导致Domino的Response中Cookie的Domain属性,与反向代理的域名不一致,Cookie的Domain属性,仍然是Domino服务器的域名。手机端拿到Cookie之后,再次进行请求的话,请求是发往反向代理的,浏览器认为之前拿到的Cookie不属于反向代理,所以Request的时候,不会把Cookie带上,导致认证不能通过。

解决方案:

location / {
    proxy_cookie_domain domino_server nginx_server;
}

在Nginx上这样设置后,可以让反向代理修改Cookie的Domain属性。

问题5:“问题4”的解决方案,适合反向代理服务器有域名的情况,对于没有域名的情况,虽然浏览器收到的Response中有正确的Cookie信息(从Chrom开发工具的Network页签查看,包括域名也已经经过转换成反向代理的域名),但是浏览器却没能正常保存这个Cookie(从Chrom开发工具的Application页签查看Cookie)。这一点比较奇怪,Java写的程序,通过反向代理后,不论反向代理是IP还是域名,浏览器端都可以正常拿到Cookie并保存,具体原因还没搞清。不知是否Domino服务器是否有什么特别的安全设置。

解决方案:
在Domino服务器所在的内网,增加另一台Java服务器,经过反向代理的请求,先发给这台Java服务器,由这台Java服务器将Request转发至Domino,收到Domino的Response之后,抽取Cookie,并进行设置,以保证返回给浏览器的Cookie能被保存。
至此,服务器部分问题解决。


补充说明:

“问题5”中,开始的解决方案,是Java服务器将拿到的Cookie通过Response的Body返回,由页面JS将Cookie写入。但是这种方案,当页面位于服务端时有效(跨域一样有效),但是对于通过Electron打包的本地页面,JS无法将Cookie正常写入,这一点也暂时原因不明,不知道是否是由于浏览器认为本地页面写的Cookie与服务端跨域?对于本地页面,还是需要服务端在Response中正常返回Cookie。

问题6:iOS版集成Cordova后,通过本地页面访问服务器,收到的Cookie不能正常保存,但是直接使用Cordova打包是可以的。

解决方案:
发现Cordova直接打包的应用,AppDelegate继承自原来的CDVAppDelegate,这个类初始化时执行了:

    NSHTTPCookieStorage* cookieStorage = [NSHTTPCookieStorage sharedHTTPCookieStorage];

    [cookieStorage setCookieAcceptPolicy:NSHTTPCookieAcceptPolicyAlways];

    int cacheSizeMemory = 8 * 1024 * 1024; // 8MB
    int cacheSizeDisk = 32 * 1024 * 1024; // 32MB
    NSURLCache* sharedCache = [[NSURLCache alloc] initWithMemoryCapacity:cacheSizeMemory diskCapacity:cacheSizeDisk diskPath:@"nsurlcache"];
    [NSURLCache setSharedURLCache:sharedCache];

将这部分代码加入自己应用的初始化部分即可。

nginx.conf 完整配置
location /myapp {
     add_header 'Access-Control-Allow-Origin' '*';
     add_header 'Access-Control-Allow-Credentials' 'true';
     add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
     add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header Cookie $http_cookie;
     proxy_pass http://domino.server/;
     proxy_cookie_domain domino.server nginx.server;
     proxy_redirect off;
}

作者:舌尖上的大胖
链接:https://www.jianshu.com/p/aeed2a56a3eb
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

制作U盘引导盘,安装Ubuntu18.04系统

制作U盘引导盘,安装Ubuntu18.04系统
一、下载Ubuntu18.04系统的iso文件
Download Ubuntu Desktop
https://www.ubuntu.com/download/desktop
镜像下载地址
https://mirrors.tuna.tsinghua.edu.cn/ubuntu-releases/18.04.1/ubuntu-18.04.1-desktop-amd64.iso
下载后的文件:ubuntu-18.04.1-desktop-amd64.iso

二、制作U盘启动系统
下载软件:
Rufus
https://rufus.akeo.ie

插入U盘后,直接双击下载的fufus.exe(绿色免安装)启动,
按照如图设置后,软件会把ubuntu-18.04.1-desktop-amd64.iso文件,写入U盘,制作系统启动盘。

三,设置电脑的BIOS从U盘系统。
———————
作者:wisespray
来源:CSDN
原文:https://blog.csdn.net/wisespray/article/details/81608578
版权声明:本文为博主原创文章,转载请附上博文链接!