每周一坑-【4月第4周】
又到每周一坑时刻，实际坑的是我 = =，今天无例外也是两坑
一、nginx配置二级域名转发报错证书不认
话说我们有个新活动，需要部署正式版（阿里云）和测试版环境（天翼云），其中测试版部署下来很顺利，因为使用到的二级域名，假设叫：acttest.ljy.cn，里面nginx虚拟主机配置上没有配置匹配根目录的访问规则，类似这样：
server { ... location / { proxy_pass http://127.0.0.1:某端口; access_log 某日志名的路径; } .... }
部署正式版环境就不行了，因为nginx上面的二级域名都有匹配到根的配置，要问我这个怎么发现的呀，因为我特意试过 “公网ip+端口/项目目录/ ”能访问，但是“域名/项目目录/” 访问不行，怀疑这个项目加载了根目录下的一些静态文件，出不来导致的。所以只能申请新的二级域名给正式活动用，这个申请需要别人帮忙搞，今天终于给我申请下来了。
然而部署到nginx上之后，报错了，如下图：
访问act.ljy.cn/xxx210426 ，直接跳到 mdx.ljy.cn/xxx210426 了
我昨天确实测试的时候，在mdx.ljy.cn 配置过一条 location /xxx210426 的规则，但是后来我去掉，重新加载nginx还是跑到那个域名上。
经验不足的我一开始是质疑这个人给错了证书文件给我，说域名申请信息可能填得不对导致转到另一个二级域名的，随后他发了域名申请的详细信息给我，我才排除是证书填写内容申请错的情况。
首先，排除了nginx默认虚拟主机配置这个可能性，顺便科普下什么叫默认主机配置：如果有多个访问的域名指向这台web服务器，但某个域名未添加到nginx虚拟主机中，就会访问默认虚拟主机（泛解析），也就是会匹配写到nginx.conf 上最上一条： include extra/xxx.conf 的域名。排除这种可能性是通过调整nginx加载顺序实现的，即把这个mdx.ljy.cn的配置文件往后挪，而不是放到第一个被加载的行里。无果，访问act.ljy.cn，还是转到mdx.ljy.cn了。
然后，我用了最极端的方法，把这个mdx.ljy.cn 的nginx虚拟主机配置文件直接去掉（井号# 注释不加载，幸好没被投诉，生产环境来的），一样不行
最后，尝试在服务器上curl 这个证书，看服务器认不认，当看到这个报错之后，甚至还怀疑是不是要装一个服务器自己的证书，来支持阿里云申请的免费证书格式。
倒是“curl 部署服务器的ip/端口” 形式是可以的！！！
最终依稀想起以前好像是有遇到这个问题，就是直接把整个nginx关掉，重启。然后奇迹出现了：
pkill nginx 没有问题，能关掉；重启不行，说3000端口已经在用，3000端口是grafana监控系统在用，我去掉这个虚拟主机的加载，能成功把nginx启动。最终证书就认了。
其实仔细想想，为啥去掉mdxx.ljy.cn的虚拟主机配置加载，还是从act.ljy.cn转过去，就应该想到nginx的加载是没有生效的（嗯，敏感度还是不够）。。。现在怀疑是nginx假死导致的，因为重新加载竟然没有生效！！！
二、mysql授权数据库账户权限不生效
老实说，这个问题也是十分奇幻，开发说执行：grant all privileges on 某库.* to 某用户@'%' 且刷新权限没有生效。然后依稀我也记得我遇到过，就叫他在grant 的最后加个 indenfied by 密码，再刷新mysql权限表生效，果然就行了。（他一开始还不相信我，觉得明明有密码了还要indentiied by 密码授权用户，还担心原生产库会有影响，毕竟这授权的用户和密码本来就有的）
我也觉得很奇怪为啥要这样，暂时没空找原因，先记下来。