半夜打工之个人Web资产架构调整
本文最后更新于：7 分钟前
这次资产迁移虽然算不上多困难，但是也学到了不少东西，以此文章作为记录
首先是动机，咳，这个就说来话长了
并不是说原本vps上的资产规划多么的不好，相反的，正如所有因为第一次使用电脑导致磁盘空间不足的小白重装系统后开始学会有规划地存放各种软件和文件，我的vps在我以99/年拿下后我分外珍惜，并极其认真地去规划我的Web资产。
那我为什么还要去费心思搞这个呢，这一切的一切，还得从一台小小的mac mini说起：
是的！我下单了一台丐版的mac mini，这台mac mini的来历说来充满了戏剧性。
最开始叠上国补+教育优惠后某东的价格一度跌到近期最低（3016），但是出于某些原因，当时手上拿不出这个钱，并且在第二天刚好能拿到这笔钱。但是当我第二天拿到钱后去京东一看，我去涨价了90多（3110）！于是咬了咬牙我还是买了下来。当天下午我就一直在反复刷狗东，结果突然，我发现价格跌了回去！于是我一冲动就退掉了3110的这个订单，但是诡异的事情来了，当我再次点开那个店铺时，你猜怎么着？价格直接飞到了3186！也就是图里的这张，来来回回直接涨了170块，这能忍？（大概是最近clawbot炒的）当时由于不甘+冲动我就真的很想买一台，于是我居然鬼使神差的去了抖音买了个2999的“九成新”二手货。当天晚上和女朋友聊起这事时她直接劝我退款了，自己冷静下思考了下加上她一直撒娇（，很快我就打开抖音退款了。并在第二天下单了3186的这款。
京东物流很快，第二日就到了，然后更加戏剧性的一幕发生了，到货后第二天的下午，学弟发现了这价格又降回去了（3016）！先前几乎没接触过价保之类的我很不甘心，但凡晚两天我就能省170了啊啊啊啊啊，然后我就去看什么7天无理由退换之类的，找客服battle什么的。然后没过多久，女朋友和学弟几乎同时提到了价保，女朋友直接从我的截图里看到了七天价保，而学弟则问了下没有价保吗。总之这一来直接让我这个购物白痴重燃了希望！于是乎争分夺秒的去申请价保生怕又涨回去了
于是最终美汁汁的以最开始的最低价拿下了这台全新机子。
嗯扯了很多这个机子的来历，那么来说说为什么要买它吧。其实就是因为女朋友考研结束了，于是我就有机会和她一起玩Minecraft了，正巧最近和她两个人一起扎进了落幕曲这个整合包里，玩的不亦乐乎。我俩的联机方式其实就是tailscale p2p+对局域网开放，我的电脑同时承担着客户端（我自己玩）和服务端（给她玩）的角色。刚开始还好，但是玩到中后期她开始吐槽出现了延迟了，并且我这里也明显出现了掉帧的问题，明显是cpu和内存不够吃了。于是我只能玩一会优化一下内存，屏幕窗口缩的小小的。于是我猛想起mac mini这玩意，心想：那为啥不买一台呢？哪怕是丐版的，这可是m4的芯片啊！有什么比它更适合拿来开mc服务器呢？于是就有了最上面提到的经历。
我花了一点时间将它彻底打造成了一台“服务器”，但是随着寒假的到来，女朋友回家后，我们玩mc的机会就少了。于是这可怜的机子又慢慢的被闲置了下来，于是我想，这么好的性能不能光拿来开mc了啊，但是拿来日用这存储（256G）又不够看，在我扩容或者给它挂拓展坞之前它注定只能是做一台服务器，并且我缺少一块优秀的屏幕，现在基本上都是通过ARD来远程连接了，画质我就不多吐槽了总之就是没有长时间看下去的欲望.jpg
你现在用电脑点开下面这张图片看有多糊就是我日常看它有多糊，完全无法坚持用一整天（（（
于是我开始了自己宏大（并非）的规划，没有需求就创造需求。首先闯入脑海的就是一直跑在我wsl里的koishi bot（说起来上次用着用着还帮他挖了个洞hhhh），但是由于个人pc没办法像服务器那样长时间开机着，并且对于只有16G的机子来说一个虚拟化吃的内存可不少，于是首当其冲就是将koishi迁移过来
然后正好某天女朋友说要是能做个相册来存放我们的各种mc的截图该多好，于是我马上就在mac上整了个nextcloud，搭配tailscale食用也几乎可以做到很完美的体验了。但是女朋友恰好当时没法用电脑，她也不是很愿意在手机上装（主打一个懒（嘘）），于是我就想那整个内网穿透出来吧，这样她就能直接用我域名访问了。
于是我开始选择方案，首先想到的就是frp，但是vhostHTTPPort真的很丑陋，即便可以nginx曲线求国但是还是膈应，不够优雅。然后就是ssh隧道转发了，这倒是没啥，最大的缺点突出一个字：慢。
然后在我睡了一觉醒来后，我猛地一拍脑袋，唉我去我的vps不是也接上了我的tailnet了吗？那我直接反代我mac mini在tailnet里的ip不就好了吗？并且vps和这mac mini显然是能打通nat的，这样一来岂不快哉？于是便有了第一版的nginx配置了
url：https://cloud.potatowo.top
女朋友看了后很开心，我们轰轰烈烈整理记录我们游玩期间的截图和视频时我也在想，都做到这一步了，干脆整一下自己的Web资产吧，虽然不算多但是也几百年没去整过了，运维手册啥的估计都忘光了
然后我简单整了下便有了下述的这个结构图
整完后，我一寻思：我去这玩意是啥啊，也太丑了吧（（（，macmini突出来的这一分支咋看咋怪
然后晚上我就在琢磨要不把所有vps上的资产都整到mac mini里，这样做的好处有以下几点：
首先是vps会过期，但是mac mini像现在这样平稳的用着的话我认为这玩意能抗个十年不是问题。其次我思索用tailscale作为二者之间的桥梁的话，反代带来的延迟应该也可忽略不计了（实际体感上最难受的不是vps->macmini，而是用户->vps，因为这玩意带宽只有3Mbps，，，）。vps就算过期了nginx配置拷贝一下换台vps就能继续用了，资产方面根本不需要去关心。
其次在大厂的打工经历让我对公网->网关->服务端这种架构有一种很奇怪的执着，哪怕是作为个人用户完全没必要去整个网关啥的，但是我一直想实现一个网关，哪怕它只是对Origin进行一个白名单校验？哪怕只是在网关自己写一个webui来实现每个资产的开关？既然都整上网关了，那还把资产放在vps上？那样一点也不优雅。
于是我又开始思索。最初的方案是还是和上面nextcloud一样，tailscale作为公网nginx和内网macmini的桥梁，通过反代来获取公网的访问能力。但是下面我又面临了一个新的问题了：以什么作为内网不同应用之间的区分？或者说，公网nginx怎么判断不同的应用url从而来反代？对于诸如docker、java这类应用，它固定会在一个端口跑起来的，这自然好弄。但是对于php-fpm、开放静态文件（比如我的博客就是纯前端）这些情况，公网nginx又该如何去区分它们呢？这个我也整了几个方案：
- 最简单粗暴，直接通过内网nginx监听不同端口来作区分
- 内网nginx配置用不同子域名来区分，公网vps上配置dns来解析不同的子域名从而区分不同的资产
对于第一个方案，我顾虑的点在于nginx我平时只喜欢监听一个80端口，我个人很不喜欢这种办法。对于第二个方案又引出了两个小方案：
- 通过自建dns服务器来实现对子域名的域名解析
- 通过配置/etc/hosts来本地解析
对于第二种小方案我始终认为是一种下下策，很不美观。从而直接抛弃了，去思考第一种方案，虽然对于企业来说有个内部的dns服务器再常见不过了，但是作为个人玩家我还是得考虑考虑必要性的。我一开始选择的方案是AdGuardHome，然后就又开始思考这玩意应该部署在vps还是macmini上，为了资产的统一性我想部署在mac上，但是过了一会一个很没啥必要的顾虑让我放弃了这个念头：如果部署在vps上dns查询就是直接走回环了，快的不能再快了，如果dns服务器部署在macmini显然就会损耗一点时间，当然，就算不计较本地dns缓存这种东西的存在，一个dns查询能带来多少的网络延迟呢（（（，所以说很没必要的想法
然后就是我在macmini上先部署了AdGuardHome，肯定是要先在本地调好嘛。然后就又是各种新的问题，当我已经把nameserver配置成mac的tailnet中的ip时，它仍然默认走cloudflare的dns服务器
ping：
curl：
nslookup：
但是偏偏强行指定dns服务器来解析又没问题，说明我adguardHome那边的配置是没毛病的
最后整来整去发现是被systemd-resolved这玩意给夺舍了，只要改一下/etc/systemd/resolved.conf就行了
下图中去掉注释并将DNS填入macmini的ip就ok了
这么一波折腾下来，我算是彻底放弃了这条路了
自己就没几个资产，多开个端口能咋样（
就这样，我实现了和自己的和解，于是便有了：
嗯，总之就是和自己和解了（（
现在你看到的一切，实际都是部署在我的macmini上的
当我看到mac的nginx日志上出现了动静时，那一刻的成就感达到了巅峰。我的所有网站从此摆脱了云服务器厂商的束缚，我也正式拥有了自己的物理“服务器”了。
不过没过多久就碰到了第一个问题。当我满心欢喜地测试着我的博客时，我发现一旦我点击这个ASCII码表，就会卡住并且给我跳转到https://blog.potatowo.top:81/ascii/，但是显然这个链接是不生效的
从这个81端口可以很容易看出是内网的nginx监听的博客端口。分析原因：
nginx中默认情况下存在一个属性：port_in_redirect on;。当nginx需要给浏览器发送一个301时（比如这里为补全目录ascii/），nginx会告知浏览器应该去哪里，此处博客正运行在81端口，为保证浏览器的信息不丢失，后端nginx就会自动在url中带上:81端口。但是内网nginx并不知道在他的前方还有一个nginx反代，他认为自己是接触浏览器的一线，因此会在Location中自报家门。
最优雅的修复方式也是最简单的，在内网nginx将port_in_redirect关了即可
到这一步拓扑图看上去更加赏心悦目了，就是mac的负担大了不少（
