Cloudflare代理站点之后，访问时这个线路怎么分配的呢……还是应该先仔细读一下Anycast。好吧，先记录下实际访问的效果。
Continue reading “访问经Cloudflare CDN代理站点后的线路是什么”Category: 站|website
在21世纪，网站这种概念和实物一定会逐渐淡化并消失的。
Status-1461
刚刚试了一下通过Cloudflare Partner直接以CNAME代理某个域名站点，然后在授权DNS上设置域名解析为几个“在国内访问较快的IP”（如），速度似乎是快了些，但还是不太确定。因为之前没有做详细的测试，这速度快了些也只是“感觉”……等各种解析传播差不多之后，再测试下。
Status-1443
没忍住又注册了个域名?
Status-1434
Status-1422
因此，我选择了一款内存1GB+4核CPU的OpenVZ产品。(…)
网络服务配置笔记：WordPress w/ SSL on Ubuntu w/ Nginx, PHP and MySQL
现在看来1G内存还是有点小了，流量大了起来，有点捉襟见肘。而实际当下这些流量，大部分都是bot或者搜索引擎的蜘蛛。sigh……翻看了一下TJUPT的聊天记录记录，学弟们的自建TJUPT站貌似早先是$40一月，但不知道配置是啥；现在的配置好像是8GB+4核CPU，而多少钱又不知道了。
Status-1386
记录一下，用certbot更新已有的Let’s Encrypt证书、并添加/删除SAN（Subject Alt Names），以CN（Common Name）为web.example.com为例，只要再次重新指定本次申请证书所有在SAN中的域名即可（以将sub1.example.com与sub2.example.com加入SAN、并将web.example.com从SAN删除为例），以下命令参考[*]：
sudo certbot certonly --cert-name web.example.com -d sub1.example.com -d sub1.example.com
程序会交互地依次询问验证方式（比如Apache/NGINX安装器、certbot自己的临时web服务器、或指定webroot等[注]），如果该域名web.example.com证书已存在，则会依次提示本次新添加进入SAN的域名与从SAN中删除的域名，然后询问并确认后，会完成证书更新。这比起直接修改域名证书申请的配置文件要安全一些[*]。
[注]：这些安装器、临时服务器及指定webroot的方式实际采用的是“HTTP-01 challenge”，需要将正在申请证书的域名开放80端口；除此之外，还有“DNS-01 challenge”；参考[1，2]。
NGINX默认站点及自签名SSL证书
这篇日志记录一些配置NGINX和SSL证书的杂项。主要涉及NGINX的默认站点和SSL自签名证书生成，自己做个备份好查找。
这种情况应当是很常见的，即一台配置了HTTP服务的服务器同时伺服了多个域名（或多个IP）的网站。有时就需要有一个所谓可以catch-all的站点，来为以下这种访问来服务：
- 所有指向这台服务器的访问；
- 该访问不在已有提供HTTP服务范围内。
因此，面对各种IP的直接HTTP访问，如果该IP本身没有已部署的服务，则应有一个“默认HTTP站点”响应其请求；面对各种指向该服务器的域名的HTTP访问，如果这些域名没有部署响应的HTTP服务，则应至少有一个“默认HTTP站点”响应其请求。加上现在已是HTTPS的天下，也应使配置兼容通过https://的访问。当然我们可以把这个默认HTTP站点做的很像模像样，但还是考虑到这个默认HTTP站点所响应的页面并不是什么十分正规的页面，甚至根本不希望有人能访问到，所以这个站点的SSL证书就不用大费周章，直接在服务器上生成一个自签名证书就好了。下面的内容，就记录这两点吧。
Status-1374
Status-1173
记录一个问题：是否可以通过代理（proxy）程序解析域名的IP地址？看Proxifier的说明，这个问题的答案是否。经过尝试，有时可以解析得到一个存在域名的IP地址，有时就只能得到Proxifier自己返回的内网地址（127.8.*.*）。
话说之前有个WordPress让我头大的问题搞了我两三周了。同时存在的还有从WordPress.com下载插件/主题时会提示“A valid URL was not provided.”。刚刚终于让我发现，在WordPress进行网络连接安全检测时发现解析URL的Host之后的IP地址是内网，则会报错。
有空再整理一下思路，想想这是个啥问题呢……
Status-1141
这两天整理“工作台”（开发机上广义的工作台），想把在Windows平台的Nginx和PHP整利索了，还真不是容易的事情。在本地（localhost/127.0.0.1）上搭建的WordPress做健康检查总是出现“The loopback request to your site failed”的错误，莫名其妙。起先还以为是DNS解析的问题，甚至自己去配了Unbound……找来找去，是在Nginx以FastCGI模式支持PHP运行脚本时，脚本再调用curl访问本地链接，因php-cgi本身限制无法生成（spawn）新php-cgi而造成curl失败，从而引发错误。这个问题说来还是不那么好解释和解决的，幸好PHP 7.1以上版本的CGI可以识别PHP_FCGI_CHILDREN环境变量而自行生成新进程，终于找到了问题的根本所在[1，2]和解决办法[1，2]。最近在整理自己在Windows平台上同时运行多个不同版本PHP的记录，稍后就作为一节写进去吧（也许另开一篇更好）。