得知他新换了14700k+4070Ti的台式机，而他原来所用的是9400f与1660Ti，这原来的主机在之后便退役下来，预计作为二奶使用。由于一些其他的问题，我也得以就地实践（比如说75寸大电视装PE还是很爽，上个月还能入手4T的固态也是大户人家啊）

我们初想也是打算部署基于Proxmox VE虚拟化系统同时运行Linux与Windows的，做好核显直通，也能当作一台HTPC使用；然而由于他家的网络拓扑结构与装修布局，至少在当时没有网线、只有一个150Mbps速率的USB无线网卡的情况下，几乎不满足PVE和其他服务器系统对网络的配置要求。

综合考虑，我们决定还是裸机安装正常的Win10系统，当然会关闭更新；顺带解决了朋友对Linux知识生疏的局限性，毕竟他没有做NAS与跑Linux服务的需求。不得不说，这套硬件配置放在很多独立MC服务器对比也算是豪华级别的，可以说整台机器的资源几乎是MC独享。

配置好网络、远程桌面、电源计划，安装java运行库……这些是例行的前置条件。

朋友打算开一个1.20.1版本的Forge模组服务器，这里依然选择了广泛使用的MCSManager开服面板，不过，新版本的MCSM已经内置了Forge开服的模板，不需要再去官网手动下载服务端、再去安装运行了。虽然，我们都才知道NeoForge的存在……似乎两者暂时还是通用的，以后再说吧。

通过MCSM提供的模板，我们成功在局域网上部署并运行Forge模组的MC服务器。

众所周知，MCSM是基于NodeJS开发的；而其Windows版本由于系统特性，直接运行MCSM的前后端会同时显示NodeJS的命令行窗口，朋友不熟悉服务器的运维事项，也会用来运行其他的程序，很容易感到迷惑而误关闭。后来，我在网上发现第三方用户为MCSM编写的Windows服务项脚本包（Github地址： https://github.com/bddjr/mcsmanager-services-for-windows ），这个脚本整合基于bat的方式添加和运行面板服务，其体验类似配置Linux下的systemd，并且实现了开机自启。这样一来，运行MCSM就不会显示Nodejs的窗口了。

不过，他家暂时没办法拿到公网IP，光猫与路由器设置的是自动获取NAT而非桥接拨号的地址，这样就没有办法通过路由器端口映射直接连接了。

应急之下我想了一个变通的方案，通过frp连接到我家的公网IP转发端口，最终通过我的DDNS域名连接至他的服务器。

庆幸的是，我使用的OpenWRT虚拟路由器，可以通过软件仓库安装frp的服务端和客户端；

而在Windows平台也有一个开源的GUI界面的FRP管理器——FRPMgr，这样便可以直观地配置、降低调试和维护成本。我转发了25565、MCSM和3389（远程桌面）的端口，即使在我家和或者通过VPN隧道，也可以方便地维护他的服务器。

FRPMgr的UI很类似Wireguard在Windows的GUI软件，个人认为非常美观。系统需求Win10/Server 2016以及以上的版本。一旦运行也会加入到系统服务项中，日常并不会感知到它的存在。

同时，我还试着搭了一个FTP文件共享站，可以直接通过Windows资源管理器访问，群晖的DSM自带了相关的设置，相比WebDAV和SMB也不需要修改系统配置或者安装软件，甚至还能实现基于HMCL的模组自动更新。当然最后还是走虚拟机跑的黑群晖手动分发MOD整合包了。

至于150M的无线网卡在实际游戏体验中并未有何瓶颈，毕竟MC的带宽要求不是很高，我所提供的上行带宽也仅仅有30M左右；

反而是本地共享与远程桌面连接比较卡顿而已，朋友的14700k主机装的系统默认还是Administrator用户……引发了不少权限问题；后者关掉动画也尚可使用吧，毕竟还是30M，但对我朋友用着240Hz高刷显示器而言就不是一般的难受了……所幸朋友他还是可以物理接触显示器操作（而那个服务器配的显示器，自然也是高刷屏 2333）

久违地再一次玩上了MC，这次来的朋友有很多，也留下了许多摄影写真。

即使在游戏中我没有OP，也是权限很大的OP……像是治理附属国的感觉吧（笑）

回想起，这个博客创立本身也是考虑发很多MC的摄影，虽然已经很少有时间再专心去玩游戏了，而我在玩家之间似乎也没有什么存在感……

来源

也不知道是哪里出现的bug，大概率还是FRP穿透和缓存的锅，索性直接把博客搬到VPS上运行了，还好之前就用Webinoly备份了下。

虽然1GB的内存有点吃力，不过MariaDB的占用好像也没那么夸张，虽然很多人当成MySQL……稳定性也比FRP穿透好了很多

还是不换成SQLite了，Webinoly一键安装的WP功能配置需要依赖MySQL引擎，再转换就太麻烦了（尽管我自己的Blessing Skin皮肤站用的也是SQLite数据库）

有点后悔退租了每个月5美元的3C4G的VPS，毕竟还得吃饭。。实话说如果不是做论坛，那么高的性能其实用不到

来源

这次发一下搭建FRP穿透内网WP博客的记录……

关于FRP的简短介绍，详见之前搭建FRP的日记：搭建FRP服务端的一次吃瓜日记

初次实践

我的内网Web服务器是一个PVE中运行的虚拟机，使用Webinoly搭建基于Nginx的vhost虚拟主机；FRP的客户端frpc在OpenWRT的虚拟机安装运行；在公网的VPS搭建FRP服务端frps和Webinoly（只安装Nginx服务）

*实际上PVE在整个穿透过程中的存在感极低，去掉虚拟化不过就是同一局域网段下的两台机器，甚至完全可以把frpc和Nginx放在一起部署……

最开始我在内网的Webinoly部署了SSL证书，frps直接设置为443端口的https隧道转发到公网VPS，在内网Nginx网站conf的端口访问打开proxy_protocol协议透传IP访问

这样SSL由内网Nginx处理，FRP仅处理流量的转发工作。连接流程是这样的：

访客 → 公网frps https (443) → 内网frpc 转发 Nginx https (443 SSL)

这么做有两个弊端，不能走Cloudflare的CDN或其他服务器中转，只要加上CDN就无法访问了；此外公网VPS的IP访问也是暴露的（不能设置SSL reject handshake (444) 黑洞），不算非常安全。

后面我尝试了在公网VPS加上用Webinoly搭建的Nginx，将frp的https端口设置为8443，然后再对frp转发反向代理，实现443的端口复用（这样就可以设置黑洞了）

访客 → 公网Nginx https (443) 转发 frps https (8443) → 内网 frpc 转发 Nginx https (443 SSL)

然而这样就出现502或者无限重定向的问题了，原因是https证书的请求头（headers）改变了，相当于中间人介入，无论使用CF还是直连都不可行。而且网上很多Nginx复用frp的教程都是转发http的。

用TCP模式+upstream上游监听理论上能解决问题，然而由于我的内网Nginx服务端的IP访问配置了SSL黑洞，也就是上文提到基于域名判断的vhost模式，这个方案还是行不通。

正因为https的转发问题，让我熬夜研究了整整两天，差点猝死（）

更换思路

既然不能直接转发内网https协议处理，那就换成转发内网http的流量经由Nginx端口复用，让公网VPS上的Nginx处理SSL？这样还能用Webinoly的certbot管理证书更新。实际搭建好以后还可以打开CDN，完全可以用CF的15年证书。

此时流程变成了这样：

访客 → （CF CDN）公网Nginx https (443 SSL) 转发 frps http (8080) → 内网frpc 转发 Nginx http (80)

*frp隧道之间可通过tls加密安全传输流量

那么配置方式就变成了，在公网的VPS用Webinoly新建网站并配置SSL，而内网的Webinoly关闭SSL，保持http协议访问。即为https2http模式。

在公网Nginx的网站conf配置加入以下代码（Webinoly配置的Nginx是在#WebinolyCustomStart行下面）

location / {
      proxy_pass http://127.0.0.1:8080;
      proxy_ssl_server_name on;
      proxy_ssl_session_reuse off;
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_redirect http:// $scheme://;
      proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
}

内网的Nginx网站配置，直接在80后面添加 proxy_protocol 就可以：

# WebinolyNginxServerStart
server {
	listen 80 proxy_protocol;
	listen [::]:80 proxy_protocol;

如果用的是Webinoly还需要注释默认的全局locations和headers配置链接：

#include common/locations.conf;
#include common/headers.conf;

但如果要穿透基于WordPress的博客、获得访客的真实IP，还是需要做一些微小的工作滴（否则连评论的IP记录都会变成192.168.*.*或者127.0.0.1的本地地址）

在wp-config添加一些代码，让WP在数据库层面启用https跳转资源和FRP穿透与CDN的标头转发记录：

/* Add any custom values between this line and the "stop editing" line. */

if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS']='on';

if( !empty($_SERVER['HTTP_X_FORWARDED_FOR']) ) {
    $get_HTTP_X_FORWARDED_FOR = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
    $_SERVER['REMOTE_ADDR'] = trim($get_HTTP_X_FORWARDED_FOR[0]);
}

这时候再访问站点的主页，资源文件，如CSS样式都能够正常访问了。

实际搭建好以后感觉速度变慢了好多，毕竟家宽只有30M的上行（而且有时候我回家用RDP的话还会抢占带宽），境内外来回转去延迟也不如DDNS的说

嘛，好处是降低了租用服务器的成本，这三年的VPS反倒涨价了不少，也不送快照备份了……

来源

顺便租了一个新的日本VPS，准备把内网的FRP穿透到公网。

这次搭建FRP服务端的时候吃了一次瓜，且听本文慢慢分解：

FRP是一个内网穿透工具，是C/S模式的程序，分为客户端和服务端部署，在公网的VPS搭建服务器，可以转发客户端内网的服务……

当然这不是本文吃瓜的重点，关于FRP的介绍后续再填坑（

那么搭建FRP的服务端我一直使用的是GitHub上MvsCode的一键脚本：

https://github.com/MvsCode/frps-onekey

之前在旧的VPS，使用这个脚本搭建的FRPS，一直可以运行。原理是判断系统位数，从官方下载对应版本的服务端，然后建立系统服务和指令运行。几乎再正常不过了吧！

但是在新VPS搭建FRP的时候，怎么也启动不起来，无论是版本号还是配置文件都没有问题，第一情况以为新的VPS太便宜了（性能也很烂），难道是ARM模拟的LXC容器？差点要提交ticket工单退款之际，我突然想到，难道是脚本的问题？

于是我去比对脚本日志：

草，怎么下的是arm64的版本？

那为啥下的是ARM的版本？这要从脚本的GitHub Repo开始说起

大概是在昨天晚上（5月9号），可能是作者的API被盗，根据commit的提交记录，repo的内容全部被删，只剩一个下载链接指向名为「SetupX.exe」的Readme文件，这个URL链接还是Discord的CDN（雾）

但随后一个小时作者就恢复（补档）了脚本文件，整件事发生只有一个小时，那时候我还在睡觉……不过根据中毒Readme的URL用Google搜了一下，应该是一次大规模的Repo中毒现象。不过这和下载到ARM版本又有什么关系呢？

再去看脚本的issues区，发现有不少用户提出了：将脚本中下载地址判断系统位元代码中的amd64更换成arm64、386替换成armhf，以适配ARM处理器设备的方法：

https://github.com/MvsCode/frps-onekey/issues/59

但是这些琪露诺用户只考虑了系统位元（Bit）、并没有考虑到架构（Arch）的判断（恼），导致脚本Repo中毒以后执行下载的全变成arm版本，只能猜测是作者补档的时候没有编写判断架构的代码（

不过解决方案也很简单，只要改回去判断amd64的版本就可以了，或者自己用wget下载二进制替换到 /usr/local/frps/ 目录下。

现在就是慢慢等待再有人提出x86更新不能用的issue吧……

下篇再填FRP客户端（frpc）穿透WP博客的坑……

来源

部署方式

这次为了节省成本，我将这个WP主机部署在家里的一台PVE虚拟机上面，然后通过FRP穿透到国外的VPS上访问。

为何不直接用DDNS？虽然家里的宽带没有封锁443的https端口，显然还是考虑到国内运营商的法规风险，而穿透到外边的VPS，服务性质就完全不一样了。WP博客不太追求很高的网络性能，FRP穿透之VPS，足矣。

搭建LNMP

搭建LNMP服务用的是 Webinoly ，这是一种开源的LNMP一键包，配置非常简单，终端输入以下脚本安装：

wget -qO weby qrok.es/wy && sudo bash weby

类似国内的一些LNMP一键包，不过相对于那些自编译的一键包，Webinoly使用的是PPA作源、对WordPress原生支持、可以设置http验证和源站黑洞，设置完以后可以卸载Webinoly本体的脚本、保留PPA的LNMP服务，在安全性也比许多面板服务优秀许多；

相对于同类的WordOps和容器化的EasyEngine，Webinoly自由度和易用性都更高一些。不过缺点也不是没有，一个是只支持Ubuntu，其次没有本地的帮助手册，如果倒了可能就消失不见。

具体的命令记录先咕了，后续有空再填Webinoly的一些坑……

记得最开始用的宝塔面板，用着用着，那是经常有舒克开着轰炸机扫我的服务器（冷知识：贝塔在郑渊洁小说的一个曾用名就是宝塔）

折腾主题：Back to the 2014

好吧，WordPress最重要的是记录为主，不过到手我对如今版本开箱即用的全区块主题化不算特别满意，逐换为上一个博客的主题：自用魔改的Mateo，一个Material Design 谷歌质感风格的主题，尽力模仿了Blogger

后面还是觉得这个主题不太好看，作为个人的日记本不错，但不太适合做类似社团的博客空间。WP的Twenty年号系列主题，在2019的区块化之前的几个主题都还算不错的样子。

先试了一下我最熟悉的2017，还是和上一个主题问题一样，后面尝试其他的20系主题，最后选定了Twenty Fourteen (2014) ：这个主题支持3.1引入的文章形式，对于多媒体和日志有更好的样式，简而言之完全可以当作一个没有时间线的微博/推特/Tumblr/QQ空间使用。

但是有一个严重的问题：2014默认是不居中的，导致在大屏上显示过于靠左了，其次默认的配色锁定在了早苗绿（）所以，就这样魔改又熬了三四天的时间，在此放上我自定义的CSS代码

//整页居中
.site {
margin: 0 auto;
}

/* 立体卡片阴影 */

@media screen and (min-width: 592px){
.site-content .has-post-thumbnail .entry-header {
    box-shadow: 0px -25px 36px -20px #0000005F!important;
}
}

/* 侧边菜单渐变 */

.secondary-navigation li:hover > a, .secondary-navigation li.focus > a, .secondary-navigation ul ul {
    background-color: #00e8e8;
    background: linear-gradient(90deg, #00e8e8 20%, #ffffff00 100%);
}

/* 分类标题 */

.archive-title, .page-title {
	font-size: 2rem;
	font-weight: 300;
}

/* 彩蛋 */

.site-info {
background: rgb(163,163,163);
background: linear-gradient(180deg, 
	rgba(0,0,0,1) 1%,
	rgba(200,200,200,1) 2%,
	rgba(126,126,126,1) 5%, rgba(64,64,64,1) 50%, rgba(25,25,25,1) 50%, rgba(0,0,0,1) 100%);
}

配色可以用一个插件解决：Fourteen Colors ，根据这个插件的描述，其实插件调用的是2014主题本来的颜色选择功能，但不知道什么原因最终被砍了，好在2014还有一些保留的主题代码，得以通过这个插件进行调整。

在Steam上也有打CSGO水友识得WordPress，我真的感到欣慰，虽然不如手搓，我说那不就是Hugo或者Gatsby嘛（也许一样是技术出身？（w）

下篇再更新AJAX刷新、音乐播放器的设置……

来源