由于博客程序更换为了 Hexo，现在只能通过引用 JavaScript 脚本，来实现博客流量的统计。长时间关注我的朋友都知道，我的博客一直通过 Feed 来向读者提供完整文章内容，以方便在我更新后能让更多的人能够尽快看到文章，所以有很多我博客的观众是通过 Feed 来订阅我的博客，这样就产生一个很大的问题：这部分读者，是通过 Feed 订阅来查看我的文章的，故此这部分读者的数量我无法统计。

诚然，有很多朋友博客的 Feed 是不推送完整的文章内容的，只有标题和摘要。但这样也把订阅的流量放到了整站流量的统计里，可能通过 Referer 域名来看到一小部分的订阅用户（因为有些读者是通过本地客户端来进行订阅的，并非通过 Web 的 Feed 的订阅服务）还会造成重复统计的问题，准确性大大降低，这样也无法获取有多少读者订阅了自己的博客。

很久之前就有这个想法，一般统计订阅的思路是通过网关的访问日志，来估算有多少用户订阅了博客，但这样做一来规整数据会极其麻烦，无法可视化简单的看到具体的用户信息，二来互联网中各种爬虫、Bot 防不胜防，你压根没有办法准确的获取其大概的订阅数量。

前段时间灵光一闪，那么我其实可以根据这部分数据来做点文章，所以写了一个小项目，来解决这个问题。

举例来说，我的 Feed 订阅地址为roy.wang/feed/ 但我的订阅文件位于 roy.wang/feed/index.xml ，看过我这篇《博客托管 Cloudflare Pages 后，关于 RSS 订阅链接的问题》的朋友或者把博客托管到 Cloudflare Pages 的朋友会知道，Cloudflare Pages 是不支持将非 index.html 的页面设置为默认页面的。这样这个项目也可以顺势解决这个问题。

其核心的处理逻辑如下：

1. 当我访问 /feed/ 时，项目就会记录访问者的信息，并且返回 /feed/index.xml 文件的内容。
2. 检测访问流量，其 UA 是否包含代码中匹配的 Feed 客户端标识符。如果是，则立即将其视为有效订阅用户。
3. 如果不匹配，则开始计数。72小时内，访问3次，则视为有效订阅用户。

所有订阅用户有 3 个小时的访问冷却期，以确保单订阅用户多时 Cloudflare Workers & D1 不会产生额外费用或停机。

RSS-Stats

提前声明一下，这个小项目呢，只适合博客域名托管至 Cloudflare 的朋友来使用。

而且需要变更现在实际的订阅文件路径，但原本订阅 URI 需保留。

目前尚未验证 CNAME 接入域名是否可行。

这个小项目只是通过一种统计思路，您也可以将其二次开发，或者使用别的语言重构，来切合您自己的博客。准确性，按照我自己的需求来看，是完全够用的。

项目地址：RSS-Stats

开始部署

部署起来非常简单，首先请 Fork 本项目，使其添加到您的账号。

创建数据库

首先，在 Cloudflare 的控制台左侧的存储和数据库 –> D1 SQL 数据库 –> 右上角创建数据库。

填写数据库名称，点击创建即可。

此时，在顶部获取数据UUID，后面会用到。格式如36ef4192-973e-469e-b7b4-1536ab69b109

部署项目

在 Cloudflare 的控制台左侧的计算和AI –> Workers 和 Pages –> 右上角创建应用程序。

进入到创建 Worker 的页面后，点击 Continue with GitHub，选择刚刚 Fork 的仓库，点击下一步。

或者可以通过 Git URL 克隆公共存储库来进行部署：

1

https://github.com/roywangdev/RSS-Stats

Set up your application 此步骤，需自定义项目名，将部署命令修改为：

1
2
3
4
5

echo 'name = "rss-stats-test"\nmain = "index.js"\ncompatibility_date = "2026-01-14"\n[[d1_databases]]\nbinding = "DB"\ndatabase_id = "cf1391d8-a25e-47bb-8e90-3427137f8574"' > wrangler.toml && npx wrangler deploy

# name 填写自定义的 Workers 项目名
# compatibility_date 建议填写为部署当天的日期（格式：YYYY-MM-DD）
# database_id 填写为创建数据库获取的 UUID

完成后点击部署即可。

设置环境变量

由于未设置环境变量，故部署完成后，打开链接会显示Error: 缺少必须的环境变量配置: RSS_URL，需要设置多个环境变量：

点击项目的设置，找到变量和机密，点击添加。类型选择文本，输入完成后，点击部署。

配置项目

此时即可访问 Workers URL + STATS_PATH 即可开始初始化数据，如：

1

https://rss-stats-test.roywangdev.workers.dev/stats/

点击立即初始化数据库，然后设置账号密码。点击保存并进入后台即可登录，进入仪表盘。

此时还需要设置路径路由，FEED_PATHS 必须设置，STATS_PATH可选。

进入设置，找到域和路由，添加选择路由，配置如下：

1
2
3

区域：博客域名
Feed 路由：domain.com/feed/
Stats 路由：domain.com/stats*

注意，如果 Feed 路由和实际订阅文件 URI 是包含关系，则不要写为 /feed/ 或 /feed**

总结

这个小项目，主旨是提供一种思路，用来统计具体的订阅用户数，如果有什么未讲到的，或者大佬们有什么更好的方案，可以评论区留言一下~

一点问题

还有一点要单独说明一下，如果有朋友发现配置之后访问 /feed/多次后并没有统计，请查看该页面的响应标头是否有 X-Rss-Stats Active 的响应标头。如未有，请检查，是否如文章《博客托管 Cloudflare Pages 后，关于 RSS 订阅链接的问题》所述，已设置 URL 重写来解决 Cloudflare Pages 不支持非 index.html 文件设置为默认页面的问题。

好久没写博客了，各位好久不见。这一年真的有好多话想说，期待我今年的午马年度总结吧，把今年一年的事情，都和大家聊一聊。

原本的博客程序，使用的是我毕业论文开发的 DaRM，现在回过头来看，当年这个项目写的跟屎一样，我已经彻底的放弃维护这个项目，转投 Hexo 的阵营了。

好久没写博客，希望带来点变化，花了半天时间写出来这个主题，总体来说还是比较满意的，别的没什么话说，希望2026年，能对我好一些。

一个新的主题新的主题，希望能带来新的开始。

Lofi

极简、纯粹、黑白风格的 Hexo 博客主题。

A minimalist, black & white theme for Hexo.

项目地址：Lofi

介绍 (Introduction)

Lofi 是一款专为专注于写作的人设计的 Hexo 主题。它剥离了所有不必要的装饰，只保留最核心的阅读体验。

核心特点：

• 极简黑白设计：经典的报纸风格，耐看且不干扰阅读。
• 超快加载：体积小巧，没有复杂的动画和沉重的库。
• 响应式布局：在手机、平板和电脑上都有完美的阅读体验。
• PJAX 支持：页面切换无刷新，体验丝般顺滑。
• 评论系统：内置 Artalk 评论系统支持（自托管的隐私友好评论系统）。
• 站内搜索：原生支持本地搜索功能。

安装指南 (Installation)

就像给手机换壁纸一样简单，只需三步即可使用。

第一步：下载主题

进入你的 Hexo 博客目录，打开终端（命令行），运行以下命令：

1

git clone https://github.com/spatiostu/lofi.git themes/lofi

或者，你也可以点击 Lofi 进入仓库，直接点击右上角的 Code -> Download ZIP，下载后解压，把文件夹改名为 lofi，然后放入博客的 themes 目录下。

第二步：启用主题

打开博客根目录下的 _config.yml 文件（不是主题目录下的那个），找到 theme 这一行，修改为：

1

theme: lofi

第三步：安装必要插件

为了让主题的搜索和渲染功能正常工作，你需要安装几个小插件。在博客根目录下运行：

1

npm install hexo-renderer-ejs hexo-generator-searchdb --save

配置指南 (Configuration)

主题的配置文件位于 themes/lofi/_config.yml。你可以根据需要修改它。

1. 菜单设置 (Menu)

设置导航栏的链接。

1
2
3
4
5

menu:
  首页: /
  归档: /archives
  友链: /friends
  关于: /about

需在source目录下创建两个页面文档：about/index.md、friends/index.md。每个文档的内容可以自定义，例如：

1
2
3
4
5
6
7
8
9
10

---
title: 友情链接
date: 2024-03-20 12:00:00
type: friends
---
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
<a href="https://www.FriendDomain.com/" target="_blank" class="friend-card">
    <div class="font-bold text-lg mb-2">FriendName</div>
    <div class="text-xs font-mono opacity-60">FriendDescription</div>
</a>

2. 个人信息 (Profile)

设置你的头像和社交媒体链接。

1
2
3
4
5

avatar: /images/avatar.jpg  # 头像路径
favicon: /images/favicon.png # 网站图标
description: "这里写一句你的座右铭"
social:
  github: https://github.com/yourname

3. 评论系统 (Comments)

本主题内置了 Artalk 评论系统。如果你部署了 Artalk Server，可以在这里配置：

1
2
3
4

artalk:
  enable: true
  server: 'https://your-artalk-server.com' 
  site: '你的站点名称'

如果不需要评论功能，将 enable 改为 false 即可。

4. 底部信息 (Footer)

自定义页面底部的版权信息。

1
2

footer:
  copyright: "© 2025 你的名字"

5. CDN 配置

为了加速主题静态资源加载，你可以配置 CDN。

1
2
3

cdn:
  enable: true
  url: https://res.your-domain.com/

如不需要 CDN 加速，将 enable 改为 false 即可。

如果有什么功能需求，也可以在评论区留言一下，如果是不错的提议，我会给主题加上！

2023/05/22 更新，Leslie 大佬提出了两个问题，一个是关于 make install 会有一个报错，另一个是更新后 系统中文 和 locale 会有问题，详情可以查看评论区置顶！

在手动升级 alist 从 3.2.0 版本到 3.6.0 版本的时候，发现环境中现有的 Glibc 版本已经无法满足alist的要求了，遂升级一波，记录一下。

1

./alist: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by ./alist)

正文

默认的GCC 版本无法无法编译 Glibc 2.28。
安装GLIBC所需的依赖，该版本需要 GCC 4.9 以上 及 make 4.0 以上。
GCC 11.2版本太新，无法与Glibc 2.28兼容。

一、安装gcc-8.2.0所依赖的环境

1
2

yum install bison -y
yum -y install wget bzip2 gcc gcc-c++ glibc-headers

二、升级GNU Make 3.82到4.2.1

1
2
3
4
5
6
7
8
9

wget http://ftp.gnu.org/gnu/make/make-4.2.1.tar.gz
tar -zxvf make-4.2.1.tar.gz
cd make-4.2.1
mkdir build
cd build
../configure --prefix=/usr/local/make && make && make install
export PATH=/usr/local/make/bin:$PATH
ln -s /usr/local/make/bin/make /usr/local/make/bin/gmake
make -v

三、升级GCC

1
2
3

yum install -y devtoolset-8-gcc devtoolset-8-gcc-c++ devtoolset-8-binutils
echo "source /opt/rh/devtoolset-8/enable" >> /etc/profile
source /etc/profile

四、下载 Glibc

1
2
3
4
5

wget https://ftp.gnu.org/gnu/glibc/glibc-2.28.tar.xz
xz -d glibc-2.28.tar.xz
tar -xvf glibc-2.28.tar
cd glibc-2.28
mkdir build

五、编译安装 Glibc

1
2
3
4

cd /root/glibc-2.28/build
../configure --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin
make -j4
make install

根据服务器 CPU 性能不同，编译时间不同

六、查询支持的 Glibc

1

strings /lib64/libc.so.6 | grep GLIBC

记录一下自己升级的过程，希望大佬们斧正。

由于之前将博客全静态化了导致评论无法使用，原本是不打算做的，但是还是又挺多朋友通过各种各样的渠道联系我交流问题，故打算解决一下这个问题，方便后续交流。

我的解决方案是能自建就自建，无法自建的基本上就不考虑了。Disqus 不能自建，加之实际使用起来效果并不理想，隐私问题，还有界面不太喜欢就直接被我 Pass 掉了。

相交于 Disqus，Commento++也是不错的解决方案，但是界面不太喜欢，以及不够轻量，故没有选择，综合来考虑来看，Cusdis是非常不错的解决方案，足够轻量、支持自建、UI简洁，致使我最终选择了 Cusdis。

此处介绍两种方式 Docker、手工部署 Cusdis，均基于宝塔面板。

项目介绍

项目地址：Cusdis

Cusdis是Disqus的开源、轻量级（约5kb gzip）、隐私友好的绝佳替代品，主要用于纯静态化网站。

Cusdis 并非旨在成为 Disqus 的完整替代品。它的目的是为小型网站（例如您的静态博客）实现一个极简主义和可嵌入的评论系统。

官方文档：Cusdis Docs

特性

• Cusdis 是开源的并且可以自我托管。因此，您拥有自己的数据。
• SDK 是轻量级的（~5kb gzipped）。
• Cusdis 不需要您的用户登录即可发表评论。
• Cusdis 根本不使用 cookie。

缺点：

• Cusdis 正处于其开发的早期阶段。
• 没有垃圾邮件过滤器，因此，您必须手动审核您的评论部分，并且在您批准之前不会显示评论。

其UI简洁、支持自托管、支持邮件推送，在邮件内即可进行批准以及回复是我比较看重的功能。

环境配置

由于 Cusdis 基于Node.js 开发，采用 SQLite 或 MySQL 或 Postgresql 数据库存储数据，所以配置要求如下：

• 系统上需要安装 Node.js 和 yarn
• 服务器上安装了 MySQL 或 Postgresql

本文基于宝塔面板，使用 SQLite 进行安装

安装配置 Node.js

如您已安装 Node.js 和yarn 并且配置成功，则此步可以跳过。

安装 Node.js 命令如下

1
2
3
4
5
6

cd /www/server/nodejs
#国外服务器选择
wget https://nodejs.org/dist/v14.15.0/node-v14.15.0-linux-x64.tar.gz
#国内服务器选择
wget https://registry.npmmirror.com/-/binary/node/v14.15.0/node-v14.15.0-linux-x64.tar.gz
tar -zvxf node-v14.15.0-linux-x64.tar.gz

设置 Node.js 全局变量：

在宝塔面板打开 /etc/profile 文件，将以下配置输入文件最后面，并保存

1
2

export NODE_HOME=/www/server/nodejs/node-v14.15.0-linux-x64
export PATH=$NODE_HOME/bin:$PATH

输入以下命令用于重载全局配置。

1

source /etc/profile

输入 node -v 和 npm -v 返回以下信息即配置完成

配置成功

安装 yarn

1

npm install -g yarn

查看版本信息，如遇 yarn：未找到命令，请看：《NodeJS 和 npm 配置全局变量》

国内服务器此步骤由于 Node.js 没有大陆节点，速度较慢。请耐心等待

千万不要使用淘宝的 registry 镜像源！！！！！！！！

否则安装依赖会出错！！！！！！！！

部署 Cusdis

此处介绍两种方式部署，手动部署与使用Dokcer

手动部署

一、克隆仓库

1
2

cd /www/wwwroot
git clone https://github.com/djyde/cusdis.git

二、安装 Cusdis 所需依赖

国内服务器此步骤由于 Node.js 没有大陆节点，速度较慢。请耐心等待

千万不要使用淘宝的 registry 镜像源！！！！！！！！

否则安装依赖会出错！！！！！！！！

1
2

cd cusdis
yarn install

三、配置 .env 文件

在 cusdis 文件夹中新建一个名为 .env 的文件

文件具体配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

USERNAME=admin
PASSWORD=password
JWT_SECRET=ofcourseistillloveyou
NEXTAUTH_URL=http://IP_ADDRESS_OR_DOMAIN
HOST=http://IP_ADDRESS_OR_DOMAIN
DB_TYPE=sqlite
DB_URL=file:./data.db
#以下配置为 EMAIL 配置 可选
SMTP_HOST=smtp.gmail.com
SMTP_PORT=465
SMTP_SECURE=true
SMTP_USER=your gmail email
SMTP_PASSWORD=<app password>
SMTP_SENDER=your gmail email

其中

1
2
3
4
5
6
7
8
9
10

PASSWORD 为密码
JWT_SECRET 为 JWT 令牌
NEXTAUTH_URL 与 HOST 需要填写项目所用的域名/IP
DB_TYPE、DB_URL 为 数据库类型、数据地址
SMTP_HOST 为 SMTP 主机
SMTP_USER 为 SMTP 用户名
SMTP_PASSWORD 为 SMTP 密码
SMTP_SENDER 为发件人电子邮件地址
SMTP_PORT 为 SMTP 端口 默认为 587
SMTP_SECURE 为是否启用 SMTP 安全，默认值为true

四、构建 Cusdis

1

yarn run build:without-migrate

这一步可能会出现错误，错误代码如下：

1
2
3
4
5
6
7

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! cusdis@ db:generate: `prisma generate --schema ./prisma/$DB_TYPE/schema.prisma`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the cusdis@ db:generate script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

这一步需要到 ./cusdis/prisma 选择需要设置的数据库类型，然后将该文件夹内的 schema.prisma 文件 复制到 ./cusdis/prisma 构建即可解决。

五、运行 Cusdis

1

yarn run start:with-migrate

设置程序守护，此处以systemd为例

打开目录 /usr/lib/systemd/system/

新建文件：cusdis.service

文件配置如下(以下配置仅供参考)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[Unit]
Description=CusdisServer

[Unit]
Description=CusdisServer

[Service]
ExecStart=/www/server/nodejs/node-v14.15.0-linux-x64/bin/npm start
Restart=always
Environment=PATH=/usr/bin:/usr/local/bin:/www/server/nodejs/node-v14.15.0-linux-x64/bin
Environment=NODE_ENV=production
WorkingDirectory=/www/wwwroot/cusdis/

[Install]
WantedBy=multi-user.target

此时保存即可，运行：

1
2
3
4
5
6

# 更新配置
systemctl daemon-reload
# 启动服务
systemctl start cusdis
# 设置开机启动
systemctl enable cusdis

详细的管理命令如下：

1
2
3
4
5
6
7
8
9
10
11
12

# 启动服务
systemctl start cusdis
# 设置开机启动
systemctl enable cusdis
# 停止服务
systemctl stop cusdis
# 重启服务
systemctl restart cusdis
# 查看状态
systemctl status cusdis
# 更新配置
systemctl daemon-reload

Docker部署

一、获取镜像

镜像名如下：

1

djyde/cusdis

国内服务器获取镜像会极慢，请耐心等待。

二、创建容器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

配置如下：
容器端口：3000
容器目录：/data
环境变量：
  -e USERNAME=admin \
  -e PASSWORD=password \
  -e JWT_SECRET=ofcourseistillloveyou \
  -e DB_URL=file:/data/db.sqlite \
  -e NEXTAUTH_URL=http://IP_ADDRESS_OR_DOMAIN \
其中
USERNAME 为用户名
PASSWORD 为密码
JWT_SECRET 为 JWT 令牌
NEXTAUTH_URL 需要填写项目所用的域名/IP
DB_TYPE、DB_URL 为 数据库类型、数据地址

#以下配置为 EMAIL 配置 可选
SMTP_HOST=smtp.gmail.com
SMTP_PORT=465
SMTP_SECURE=true
SMTP_USER=your gmail email
SMTP_PASSWORD=<app password>
SMTP_SENDER=your gmail email

启动完成。

后语

设置反向代理

宝塔新建站点 -> 打开SSL - > 反向代理 ->添加反向代理

目标 URL 填写：http://127.0.0.1:3000

配置站点

进入页面登陆，然后创建一个默认的网站，选择 Embed Code ，复制代码到网站的合适位置即可。

WordPress 配置

以下配置仅供参考，主要包括 data-page-id、data-page-url、data-page-title

1
2
3

data-page-id="<?php the_ID(); ?>"
data-page-url="<?php $id =get_the_ID();echo get_permalink($id); ?>"
data-page-title="<?php the_title(); ?>"

跨域问题

最开始使用的时候可能会出现跨域问题。

在反向代理的配置文件中添加：

1

add_header 'Access-Control-Allow-Origin' 'yousitedomain';

两种方法，更推荐 DOCKER 如选择手工安装，可能会遇到各种各样的问题。

看了很多使用 acme.sh 签发 通配符 SSL 的教程，但讲的比较笼统，所以打算写个详细教程记录一下。

此处以 ZeroSSL 为例，acme.sh也可签发其他证书，可自行研究。

不同品牌证书之间优劣不在此赘述。

2024-08-18更新：增加安装证书以及自动续期。

部署 ACME.SH

下载 acme.sh

1

curl  https://get.acme.sh | sh

创建文件链接

1

alias acme.sh=~/.acme.sh/acme.sh

切换证书为 ZeroSSL

1
2
3

acme.sh --set-default-ca --server zerossl
#国内服务器推荐 letsencrypt
acme.sh --set-default-ca  --server  letsencrypt

获取zeroSSL eab

打开 https://app.zerossl.com/developer

注册账号并登录，打开页面后点击 Generate

绑定邮箱，输入你注册使用的邮箱

1

acme.sh --register-account -m YourEmail

获取 EAB KID 和 EAB HMAC Key 并且按格式填写

1
2
3

acme.sh  --register-account  --server zerossl \
         --eab-kid  EAB KID \
         --eab-hmac-key  EAB HMAC Key

获取DNSPOD API

这里是通过自动 DNS 解析来进行 DNS 验证，也可选择文件验证，但推荐自动验证。

此处以 DNSPOD为例，其他运营商操作类似。

打开 https://console.dnspod.cn/account/token/token 获取 ID/KEY

配置DNSPOD API

1
2

export DP_Id="YourID"
export DP_Key="YourKey"

自动签发通配符

1

acme.sh --issue --dns dns_dp -d *.domain.com -d domain.com --keylength ec-256

此时证书签发成功，绿色的部分为证书的存储路径，部署在服务器即可。

fullchain.cer 是证书内容，xxx.key 是证书的私钥。

安装证书及自动续期

在 shell 命令行输入以下命令

1
2
3
4

acme.sh --install-cert -d *.domain.com -d domain.com  --ecc \
--key-file   /cert/domain.com/privkey.pem  \
--fullchain-file /cert/domain.com/fullchain.pem \
--reloadcmd     "service nginx force-reload"

其中具体的目录以及域名需要手动修改。

后语

步骤可能有错误，希望大家斧正。

之前介绍过，我的博客方案已经更换为全静态，详细可以参考我这篇文章《WordPress “纯”静态化》

理论来说，所有静态资源回源一遍之后，后面的请求都会直接从CDN获取资源，并不会进行回源操作，除非我更新了资源，并且手动刷新资源。

但长久以来，还是从源站上看到了许多已经回源过的资源，而绝大多数的特征都在于 ‘?’ 这个符号之后。遂才想起，忘记了做 ignore query string，此篇文章谨当记录一下操作过程。

正文

之前文章介绍过，我是通过 NS 解析时，将请求划分为境内与境外，境内使用了 腾讯云CDN，境外为CloudFlare。所以此文也分为两个步骤分别进行。

Tencent Cloud CDN

未进行 ignore query string 操作时，在网址后面输入 ‘?*’ 时会自动回源。

此时，在腾讯云CDN的域名管理之中找到缓存配置，修改全部文件配置

修改为下图所示即可：

此时即可看到，没有回源，命中了缓存。

CloudFlare

未进行 ignore query string 操作时，在网址后面输入 ‘?*’ 时会自动回源。

在页面规则中，新增以下配置：

1
2
3
4

URL (required) ：*youdomain/*?*
Pick a Setting (required)：Forwarding URL
Select status code (required)：301 - Permanent Redirect
Enter destination URL (required)：https://$1youdomain/$2

如下图所示：

此时再进行 query string 操作时，CloudFlare便会自动的301跳转到无 query string 操作的页面，以达到ignore query string的效果

本方法可能不适用于您的站点，请慎重参考。

由于 umami 不再使用 npm 构建，而是改为了使用 yarn 构建安装的方式，所以今天把 umami 删除，重新构建了一遍。

yarn 安装完成后，使用直接报错，查到因为没有配置 npm 成为全局变量，此文记录一下配置过程。

配置

1、获取 npm 安装目录

1

npm bin -g

2、创建软链接

1

ln -s 获取到的地址/npm /usr/local/bin/npm

3、配置用户环境变量

1
2

cd ~   #切换到用户根目录
vi .bash_profile   #修改用户环境变量文件

输入 i 切换为输入模式，在 PATH=$PATH: 行后，添加 :第一步获取到的目录，然后按 esc 推出输入模式，切换到命令模式输入 :wq 之后保存并退出。

5、重启配置文件

1

source .bash_profile

6、查看 npm 和 yarn 配置

1
2

npm -v
yarn -v

此时 NodeJS 和 npm 全局变量即配置成功

目前博客的 CDN 方案是通过DNS识别境内境外IP，进行不同的解析的，但是使用 CloudFlare 会导致一部分跨域问题，使某些样式无法正常加载，不过最终还是找到了解决方案，记录一下。

配置

#2022-11-6更新一位MJJ大佬提供的更好的方法

在域名左侧选择规则->转换规则

选择修改响应头

具体配置如下图所示：

以下为旧方法，不太推荐使用：

百度出的方法，基本上都是从服务器配置 NGINX 取消跨域限制来解决，但是这样也会伴随着许许多多的问题。CloudFlare也发布了文章，通过 CloudFlare Worker 稍微配置一下即可解决这个问题。

一、创建 CloudFlare Worker 服务

设置服务名称，然后选择 HTTP 处理程序

二、点击快速编辑，将以下代码复制到其中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

// Reference: https://developers.cloudflare.com/workers/examples/cors-header-proxy
const corsHeaders = {
        "Access-Control-Allow-Origin": "*",
        "Access-Control-Allow-Methods": "GET,HEAD,POST,OPTIONS",
        "Access-Control-Max-Age": "86400",
}
function handleOptions (request) {
        // Make sure the necessary headers are present
        // for this to be a valid pre-flight request
        let headers = request.headers
        if (
                headers.get("Origin") !== null &&
                headers.get("Access-Control-Request-Method") !== null &&
                headers.get("Access-Control-Request-Headers") !== null
        ) {
                // Handle CORS pre-flight request.
                // If you want to check or reject the requested method + headers
                // you can do that here.
                let respHeaders = {
                        ...corsHeaders,
                        // Allow all future content Request headers to go back to browser
                        // such as Authorization (Bearer) or X-Client-Name-Version
                        "Access-Control-Allow-Headers": request.headers.get("Access-Control-Request-Headers"),
                }
                return new Response(null, {
                        headers: respHeaders,
                })
        }
        else {
                // Handle standard OPTIONS request.
                // If you want to allow other HTTP Methods, you can do that here.
                return new Response(null, {
                        headers: {
                                Allow: "GET, HEAD, POST, OPTIONS",
                        },
                })
        }
}
async function handleRequest (request) {
        let response
        if (request.method === "OPTIONS") {
                response = handleOptions(request)
        }
        else {
                response = await fetch(request)
                response = new Response(response.body, response)
                response.headers.set("Access-Control-Allow-Origin", "*")
                response.headers.set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
        }
        return response
}
addEventListener("fetch", (event) => {
        event.respondWith(
                handleRequest(event.request).catch(
                        (err) => new Response(err.stack, { status: 500 })
                )

点击保存并部署

三、点击触发器，然后添加路由

填写需要解决跨域问题的域名，如多个文件在同一问题下，可直接通过 * 替代

之后即可解决 CloudFlare CORS 跨域问题。

出于安全原因，请只选择真正需要解决 CORS 错误的路径

可添加多个路由解决多个站点的问题

前几天才发表了 WordPress 的 CDN 方案，但是很快就反水了，并不是因为那个方案不够好，而是越写博客越发现，静态博客才是个人博客应有的终极形态。

很多朋友都在劝我抛弃 WordPress 转投 Hexo 的怀抱，不过确实，“纯”静态博客个人才是博客应有的样子。为什么要加一个“纯”呢？就像 WordPress，很多人通过伪静态，把页面后缀改为 html，再使 CDN 强制缓存，达到一个静态的效果。但这样的 伪静态 并非 静态博客 的真正样貌。

为什么不使用 Hexo 或者其他方案，因为仅 Hexo 对我来说是完全陌生的，而且其所使用的技术栈，也是我完全不懂的。相较于使用一些完全不懂的东西，不如去继续把手头正在用的改造的更好，毕竟内容才是博客最主要的。

方案选择

选择 WordPress 的理由

其实对于 WordPress 的理由有很多，无论是一些非常好用的插件，还是 Gutenberg，还是整个操作逻辑，对于软件使用的熟练使用程度，其所使用语言对目前我来说一些基本操作都能够实现。都在让我坚持使用 WordPress，以至于更换“纯”静态方案，没有将其替换掉的原因。

为什么要坚持所谓的”纯”静态

传统的 WordPress 加速解决方案都是使用 WP Super cache 之类的插件，生成缓存，然后生成 html 文件，使用 CDN 强制缓存，但这么做的问题是，虽然展示的是静态的，但其还是需要执行 SQL 语句来调用数据的，虽然目前市面上的 0SQL 主题不少，但是大多数还是无法避免这个操作。

而“纯”静态化，直接是 0SQL，无需后端，可以极大的缩少服务器资源的占用。就算你的服务器在海外，只要域名备案，通过国内的 CDN，都可以获取非常可观的速度。

目前方案的问题

目前方案主要拥有下面两个问题：搜索不可用以及评论不可用。

我对于这两个问题的解决直接放弃了。

本身国内的个人备案是不支持交互式网站的，而且垃圾评论实在是太多，以至于我后面开启了 reCAPTCHA，还是不断的有人来打广告。。。。

关于搜索，因为每个文章都拥有相应的 tag，点击一下即可显示相关文章，一部分承担了搜索的功能。

两个问题带来的影响都不算大，索性就不去管了，去专注内容。

更新不及时，需要手动去刷新 CDN 缓存。

Simply Static

插件地址：Simply Static

这是我目前所选择方案所使用到的插件，它最大的好处就是通过缓存可以直接将 WordPress 页面生成静态文件，并且可以将文件中的地址自动替换，直接放到服务器即可。

方案介绍

所需要的要求如下：

• 需要用到两个域名：
  • console.domain.com //用于 WordPress 动态资源的域名
  • domain.com //用于静态博客域名（博客的主域名）
• 两个站点都需要位于同一服务器内
• 其余要求可以打开插件 Simply Static › Diagnostics 查看有哪些地方不符合规则

配置

Simply Static 设置

原理很简单，就是通过 Simply Static 这个插件，直接在 domain.com 也就是你博客的主域名的目录里生成静态文件。

这个插件，需要进行以下设置：

GENERAL

1、Destination URLs

此处的作用是将 WordPress 生成的静态文件中 动态博客地址，转为主博客的地址（静态地址）

此处需要选择 Use absolute URLs 然后填写你博客的主域名

2、Delivery Method

此处的作用，是选择把生成的静态文件通过何种方式存储。

此处选择：Local Directory

3、Local Directory

设置生成的静态文件存储的目录

此处填写 主博客所设置的目录即可。

INCLUDE/EXCLUDE

此处设置一处：Additional URLs

输入内容主要是不包含在静态页面中的链接，但还是需要生成静态文件的链接。

此处需要设置 动态博客 的文件链接。

主要是 sitemap、robots.txt

其他设置

其他设置可根据自身需要来进行设置，诸如可以设置：附加文件和目录、要排除的 URL、

临时文件目录、HTTP 基本身份验证(此处强推)

全部设置完毕后，可以在 Diagnostics 处进行检测，当没有错误即可进行手动生成。

生成静态文件

当设置完毕，并且检测没有问题后，在 Generate 中点击 GENERATE STATIC FILES 即可生成文件，根据需要生成的文件大小不同所需时间也不同。

CDN 设置

CDN 还是采用通过 DNS 区分国内国外用户，国内用户走腾讯云，国外用户走 CloudFlare。此处与之前的方案没有改变。

因为是是纯静态文件，所以无论国内还是国外的用户都会有非常不错的体验。

此处可以参考 《目前博客的 CDN 解决方案》

无论是 腾讯云还是CloudFlare主要：

• 设置防盗链
• 开启强制缓存，并设置缓存过期时间
• 设置浏览器缓存过期时间
• 开启HTTPS
• 打开 压缩静态文件

对整个网站做出更改后，可以通过 腾讯云CDN、CloudFlare 两个 WordPress 实现刷新缓存，目前无其他比较好的方法。

折腾来折腾去还是找到了对我还是对用户来说都最好的解决方案，接下来就是专心写文了。

很多时候，WordPress 更换域名是一件及其麻烦的事情，一则需要手动去修改数据库，二则不确定是否会不会有漏掉修改的地方。（作为一个博客更换过十几个域名的小老铁深受其害）

WordPress官方推出了用于管理 WordPress 的命令行工具——WP-CLI，我们只需借助其中批量修改数据库的功能即可近乎完美的快速完成 WordPress 站点的域名修改。

WP-CLI配置要求

• 类 UNIX 环境（OS X、Linux、FreeBSD、Cygwin），Windows 环境中的支持有限
• PHP 5.6 或更高版本
• WordPress 3.7 或更高版本。比最新 WordPress 版本更早的版本可能会降低功能

修改域名

一、安装 WP-CLI

使用以下命令进行安装配置 WP-CLI

1
2
3
4
5

#下载 WP-CLI
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
#配置全局变量
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

使用以下命令检测配置是否正常

1

wp --info

如果出现以下错误，则需要解禁 PHP函数：proc_open

解禁PHP proc_open 函数即可解决

配置正常返回以下信息：

配置正常

二、修改站点域名

打开 WordPress 站点目录（此处以宝塔默认为例，如您进行了其他配置，请修改

1
2
3
4
5
6
7

#打开站点目录
cd /www/wwwroot/wordpress
#测试站点需要修改的地方,此命令不会直接运行，以下命令二选一即可。
#此命令适用于 root 用户
wp search-replace 'http(s)://olddomain' 'http(s)://newdomain' --dry-run --allow-root
#此命令适用于非 root 用户
sodu -u wp search-replace 'http(s)://olddomain' 'http(s)://newdomain' --dry-run

返回以下信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

[root@localhost wordpress]# wp search-replace 'https://te1.roy.wang' 'https://te.roy.wang' --dry-run --allow-root
+------------------+-----------------------+--------------+------+
| Table            | Column                | Replacements | Type |
+------------------+-----------------------+--------------+------+
| wp_commentmeta   | meta_key              | 0            | SQL  |
| wp_commentmeta   | meta_value            | 0            | SQL  |
| wp_comments      | comment_author        | 0            | SQL  |
| wp_comments      | comment_author_email  | 0            | SQL  |
| wp_comments      | comment_author_url    | 0            | SQL  |
| wp_comments      | comment_author_IP     | 0            | SQL  |
| wp_comments      | comment_content       | 0            | SQL  |
| wp_comments      | comment_approved      | 0            | SQL  |
| wp_comments      | comment_agent         | 0            | SQL  |
| wp_comments      | comment_type          | 0            | SQL  |
| wp_links         | link_url              | 0            | SQL  |
| wp_links         | link_name             | 0            | SQL  |
| wp_links         | link_image            | 0            | SQL  |
| wp_links         | link_target           | 0            | SQL  |
| wp_links         | link_description      | 0            | SQL  |
| wp_links         | link_visible          | 0            | SQL  |
| wp_links         | link_rel              | 0            | SQL  |
| wp_links         | link_notes            | 0            | SQL  |
| wp_links         | link_rss              | 0            | SQL  |
| wp_options       | option_name           | 0            | SQL  |
| wp_options       | option_value          | 2            | PHP  |
| wp_options       | autoload              | 0            | SQL  |
| wp_postmeta      | meta_key              | 0            | SQL  |
| wp_postmeta      | meta_value            | 0            | SQL  |
| wp_posts         | post_content          | 2            | SQL  |
| wp_posts         | post_title            | 0            | SQL  |
| wp_posts         | post_excerpt          | 0            | SQL  |
| wp_posts         | post_status           | 0            | SQL  |
| wp_posts         | comment_status        | 0            | SQL  |
| wp_posts         | ping_status           | 0            | SQL  |
| wp_posts         | post_password         | 0            | SQL  |
| wp_posts         | post_name             | 0            | SQL  |
| wp_posts         | to_ping               | 0            | SQL  |
| wp_posts         | pinged                | 0            | SQL  |
| wp_posts         | post_content_filtered | 0            | SQL  |
| wp_posts         | guid                  | 3            | SQL  |
| wp_posts         | post_type             | 0            | SQL  |
| wp_posts         | post_mime_type        | 0            | SQL  |
| wp_term_taxonomy | taxonomy              | 0            | SQL  |
| wp_term_taxonomy | description           | 0            | SQL  |
| wp_termmeta      | meta_key              | 0            | SQL  |
| wp_termmeta      | meta_value            | 0            | SQL  |
| wp_terms         | name                  | 0            | SQL  |
| wp_terms         | slug                  | 0            | SQL  |
| wp_usermeta      | meta_key              | 0            | SQL  |
| wp_usermeta      | meta_value            | 0            | PHP  |
| wp_users         | user_login            | 0            | SQL  |
| wp_users         | user_nicename         | 0            | SQL  |
| wp_users         | user_email            | 0            | SQL  |
| wp_users         | user_url              | 1            | SQL  |
| wp_users         | user_activation_key   | 0            | SQL  |
| wp_users         | display_name          | 0            | SQL  |
+------------------+-----------------------+--------------+------+
Success: 8 replacements to be made.

确认需要修改的信息无误后，直接修改即可：

1
2
3
4

#此命令适用于 root 用户
wp search-replace 'http(s)://olddomain' 'http(s)://newdomain' --allow-root
#此命令适用于非 root 用户
sodu -u wp search-replace 'http(s)://olddomain' 'http(s)://newdomain'

至此数据域名修改域名完成。

这个通过 WP-CLI 修改域名还是十分方便的，但切莫忘记修改SSL、以及站点等相关信息。

之前更过一篇 WordPress 配置CDN的文章 《WordPress 配置CDN，免对象存储，加速域名首页自定义》，感觉这个方案太水了，而且后面也遇到了各种各样的问题，然后重新设计了 CDN 方案，整体来说还算是满意，今天分享出来跟大家聊聊，我会详细说一说具体的配置，以及这么做的原因和弊端。

方案导图

话不多说，直接上图

通过 DNS 进行境内境外分流

国内用户

动态资源 - 百度云加速

原因

选择百度云减速(bushi 云加速得原因很简单——收录。

绝大多数建站的站长肯定是希望盈利的，但至少是希望尽可能的去抹平每年域名、服务器、CDN的费用。可能是出于兴趣建站，毕竟谁不希望少花点钱呢？为了均衡成本，是需要通过流量来变现，而被搜索引擎收录所带来的流量一直是很可观的，事实上很多站点也是这么做的。

中文互联网内主流的搜索引擎也就是三家：百度、Google、Bing。

Google虽然情况特殊，国内用户无法访问，但是因为对百度、Bing 特供版的不满。很多人将其当作首选的搜索引擎，收录速度虽然很快，但是 关键词排名难做，特殊原因导致中文用户基数少是其主要的问题，所以所获的流量不是很多。

Bing的情况有些特殊，虽然国内可以直接访问，而且没有像百度这样充斥着广告，国内用户虽然也有存量，但由于多年被国内互联网环境培养的用户习惯导致，Bing的用户基数很小，虽然收录很快但是站长能从中获取的流量也并不是很多。

百度，虽然百度充斥着恶臭以及各种各样的问题，但其还是作为中文互联网的搜索引擎的 No.1。由于某些特殊原因，百度的SEO优化甚至演变成为了一门十分值得研究的学问，一个新的网站如果想被百度快速大量的收录，其中所需要的条件多种多样，很多高阶条件是新人站长无法满足的，此处不再详细赘述。对于无法满足的这些条件的站长，百度还是提供了一条明路——百度云加速，这也是我选择它的原因。

缺点

百度云加速的缺点很明显，慢，名为加速，实则减速。现在的免费版仅仅提供可怜的三个节点（但经过我实测只有两个）它的商业模式采用的套餐制度，如果你想拥有多节点的话，加钱，最便宜的一年四位数的那种。当然不可能花钱的，所以国内的静态资源没有托管到百度，而是使用的 腾讯云的 CDN。

配置

百度云加速的配置极其简单，甚至属于对接上就行的辣种。

打开面板打开 流量功能->引擎加速收录 里的 新站百度报到

以及在 同在 流量功能 中的 永久在线

在 其他 -> 特定页面规则 中添加规则，如下所示(此处仅以WordPress为例，其他不同程序配置不同，其中规则优先级1>2)：

1
2
3
4
5
6
7

规则1
URL:       domain/wp-admin/*
规则配置： 缓存粒度设置 -> 不缓存
规则2
URL:        domain/*
规则配置1： 缓存粒度设置 -> 细致
规则配置2：浏览器缓存有效期 -> 1天

规则1

规则2

至此配置完成。

静态资源 - 腾讯云 CDN

原因

稀里糊涂的选择了腾讯云 CDN，主要是可是白嫖，可能感觉服务器也是腾讯云的可能有特殊加成（？）不太记得了，但是使用了之后的体验还是非常不错的，比我用过的 UPYUN 还有 百度云加速 感觉好。

缺点

目前使用起来没感受到啥明显缺点，但是可能以后会感受到，毕竟不是一直可以白嫖的，未来的缺点就是贵。不对，这是我的缺点

配置

分享一个我使用回源策略，回源 HOST 填写 加速域名，然后在这个域名对应的站点目录中创建 软连接软件，然后将 WordPress 站点目录链接至 CDN 加速域名的站点目录，如下图所示：

完成初步配置后(指接入CDN)，因为公开的加速服务不理想，所以我直接通过国内的服务器进行了反代，然后设置缓存，然后通过腾讯云CDN缓存起来，网站速度提升了一大截。

但由于此服务仅是供自己使用的，所以需要打开防盗链。

进入CDN域名管理页面->访问控制，第一个既是防盗链，输入需要访问资源的域名即可。其余配置如下图：

进入缓存配置->缓存键规则配置，设置为全部文件，不忽略参数，不忽略大小写

缓存配置->节点缓存过期配置，新建规则如下：

1
2
3

类型：文件后缀
内容：jpg;png;js;css;ico;woff2;woff;tff
缓存行为：缓存七天，强制缓存

回源配置 -> 回源跟随301/302配置 打开

HTTPS配置 -> 强制跳转 打开

高级配置 -> HTTP响应头配置 (此项配置是为了防止出现 CORS 错误

1
2

头部参数：Access-Control-Allow-Origin
头部取值：你需要引用静态域名的域名，如图示例。

打开 高级配置 -> 智能压缩，如下图所示：

至此，CDN配置完毕，但是 WordPress 需要将静态资源地址替换为加速地址

此处以 WPJAM BASIC 插件为例（强推），选择云存储 腾讯云COS，然后输入加速的 CDN 域名。

保存即可，此操作可替换绝大多数静态资源链接，也可以通过反代配置自己的 Google字体加速、Gravatar加速。

国外用户

动态+静态资源 - CLOUDFALRE

原因

免费还是很香的，而且提供免费的防御，国外 CloudFlare 的速度还是非常快的。主要还是能白嫖。

缺点

无。。。。。。。可能对国内速度不佳？

配置

CloudFlare 的配置堪称傻瓜式的，也是通过 峰峰 的教导，才正确的打开了 CloudFlare 的配置方式

本站采用的是 CNAME接入，详细的接入教程参考本站文章 《CLOUDFLARE 免费官方 CNAME 接入》

目前我的配置方法就是在 规则 -> 页面规则 中添加一条页面规则，具体配置如下：

1
2
3

URL: domain/*
设置1：缓存级别 -> 缓存全部内容
设置2：边缘缓存TTL -> 1个月

为什么不设置 /wp-admin/* 为不缓存。因为免费规则只有三条，超出就要收费，另外在国内不需要访问海外线路的 /wp-admin/

选择 速度 -> 优化 Auto Minify，三个选项全选

启用 Brotli

至此 CDN 优化方案完成，此方案还是存在很多暂时没有发现的问题，可能会有更好的方案。能力至此，希望各位斧正。

此方案也是目前博客所使用的方案。

曾经有段时间，事情很多，每天早上起来都不知道何从下手，以致越忙越乱。很多不该搞杂的事情让我给搞砸了。

后来养成了把东西写下来的习惯、但是这样不够方便、也不能随时想看就看，也是非常苦恼的。

现在市面上很多待办程序，无论是 微软待办 还是其他的待办程序，都比较臃肿。

最主要是数据全部不在自己手中，这是我无法接受的。

项目简介

项目官网：myTinyTodo

该项目基于 PHP(54-74) 和 jQuery开发。支持 SQLite 以及 MySQL

特性

• 多个任务列表
• 支持标签
• 设置截止时间
• 设置任务优先级
• 密码保护
• 不同的排序，包括拖放排序

你如果也有类似的苦恼，个人感觉这个项目可以解决这部分问题。

配置 myTinyTodo

一、打开网站下载程序。

二、新建网站并且将下载下来的文件上传到站点目录并解压

三、打开以下地址运行安装程序

1

http(s):// youdomain /setup.php

此时需要选择使用的数据库，这里目前有个问题，暂时不了解作者所设计的 MySQL数据库 的逻辑，但导入数据无法备份恢复数据。

总而言之一句话，不要使用 MySQL 请选择 SQLite

点击 install 进行安装

安装完成，请删除目录下的 setup.php

四、设置

设置其中只讲一点，有关于 会话处理机制（Session handling mechanism）请选择 PHP，否则会出现意想不到的错误。

此时即可开始设置使用。

后语

有关程序的升级：保留程序目录的 DB 目录以及其中文件，其他目录以及文件直接用新目录覆盖即可。

这也是我目前所使用的一款 todo 程序，如果使用得当，可以大大提高生活以及学习效率。

CloudFlare 是很多站长在建站时首选的 CDN 服务商，免费、无限带宽，抗DDOS，都是选择它的理由，但由于某些方面原因，使得国内的访问速度堪忧。由于 CloudFlare 的 NS 服务器在国外，所以还需要尽可能的降低延迟，来提升网站体验，所以就有了CNAME 接入这种方式，使用国内的 NS服务器，可以一定程度缓解加载时间过长的问题。

之前可以使用 CloudFlare 提供的合伙人密钥，使用第三方网站进行添加 CNAME 接入，但由于目前 CloudFlare 的防滥用政策日渐缩紧，所以禁止了通过合伙人密钥来进行添加 CNAME 接入。各家第三方的接入平台如 笨牛网 等已经禁止了用户登录。

但目前 CloudFlare 提供了一种官方 CNAME 接入的方式。

CloudFlare for SaaS

之前使用这个功能是收费的，但自 2022/3/15 起，官方开启了免费额度。每个账户拥有目前 100 个CNAME接入的免费额度，而超过 100 的部分也由每月 2美金 每个的价格降低至了每月 0.1美金 每个。

我们所依赖这个功能所提供的免费额度，来实现免费 CNAME接入。

配置 CNAME 接入

在配置之前，您需要准备两个域名以及PayPal账号：

1
2

a.com : 此域名需要通过 NS 的方式接入CloudFlare
b.com : 此域名即为你需要加速的域名。

如何通过 NS 接入，不再详细演示。

开通CloudFlare for SaaS

打开网站配置页面，并且找到 SSL/TLS 下的自定义主机名。

订阅 CloudFlare for SaaS 需要绑定外币信用卡或 PayPal，个人建议绑定PayPal（此过程不会发生扣费）

由于之前已经开通过了，所以无法演示，根据页面提示进行操作即可。

设置回源域名

在配置 CNAME 接入之前，需要设置回源所需的域名。

在DNS选项中，设置一个自定义的接入CloudFlare的二级域名（即使用上文中提到的 a.com 设置一个二级域名解析到你的网站IP），解析至需要回源的 IP 或域名，并且打开 CloudFlare 的代理。

然后打开 SSL/TLS 下的自定义主机域，在回退源中，填写设置好的域名，并且点添加回退源，等待生效。

此时即可增加需要 CNAME 接入的域名

点击添加自定义主机名，输入你需要接入的域名，并且选择最低TLS版本（如不懂，请保持默认）以及证书验证方式即可。点击添加自定义主机名。

设置国内 NS 服务商 DNS 解析

提交后，即可看到正在初始化，在第三方的 NS服务商处设置好相应的NS解析，等待检测即可。

并且同时，需要将 需要接入的域名 解析到 回源域名 上

全部设置完成后即可等待解析生效。

解析生效

解析生效

此种方法需要 PAYPAL 账号，而且好处相比第三方，数据保存在自己的手上。

而且所有关于 CNAME 接入的相关设置与统计数据，均与 通过 NS 接入的域名共享。

现在由于服务器带宽太小，为了节省带宽资源，已经很多站点都在使用图床。

很多人都在使用如 WeiBo、Gitee 此类平台为图床，由于使用人数、成本增加过高，这些平台也相继开启了防盗链。现在绝大多数都无法再作为图床使用。

此时如果选择自建图床，配合诸如 百度云/又拍云 此类拥有免费额度的 CDN 还是非常不错的。

曾经也有计划构思过做开放的免费图床，但是许多程序的性能还有UI设计大多不太满意，还有成本原因所以没有开放，一直都是自用。

前段时间发现 Lsky Pro 更新了 2.0 版本，以前用过 1.0 的版本但是整体UI不太满意，但是看了 2.0 的版本，UI还有性能也非常满意，借着这个机会做了免费的图床：PUBLIC IMAGE SERVICE 有需要的朋友可以看一下。

项目简介

项目地址：Lsky Pro

文档地址：Lsky Pro Docs

特性

• 支持本地等多种第三方云储存 AWS S3、阿里云 OSS、腾讯云 COS、七牛云、又拍云、SFTP、FTP、WebDav、Minio
• 多种数据库驱动支持，MySQL 5.7+、PostgreSQL 9.6+、SQLite 3.8.8+、SQL Server 2017+
• 支持配置使用多种缓存驱动，Memcached、Redis、DynamoDB、等其他关系型数据库，默认以文件的方式缓存
• 支持图片水印、文字水印、水印平铺、设置水印位置、X/y 轴偏移量设置、旋转角度等
• 支持通过接口上传、管理图片、管理相册
• 支持在线增量更新、跨版本更新

环境需求

• PHP >= 8.0.2
• PHP 拓展：BCMath、Ctype、DOMFileinfo、JSON、Mbstring、OpenSSL、PDO 、Tokenizer、XML、Imagick
• PHP 函数：exec、shell_exec、readlink、symlink、putenv、getenv

配置 Lsky Pro

本教程基于宝塔进行。

下载安装包

打开 Lsky Pro releases 选择最新版本下载。注：请不要下载 Source code

新建站点，将安装包上传到网站目录并解压

创建数据库

在宝塔面板左侧选择 数据库->添加数据库 输入相关信息即可提交

设置网站相关配置

关闭 放跨站攻击、修改网站运行目录：打开站点设置->站点目录，把 防跨站攻击(open_basedir) 前面勾取消，运行目录选择 /public

设置站点伪静态：选择 伪静态，输入以下伪静态规则，然后保存：

1
2
3

location / {
  try_files $uri $uri/ /index.php?$query_string;
}

配置 SSL，PHP 版本切换为 8.0

运行环境配置

打开 PHP 设置，配置相关运行环境，由于宝塔默认已经安装了部分相关拓展，开启了部分相关函数，仅需配置以下函数、拓展即可

• 安装拓展：fileinfo、imagemagick
• 开启函数：readlink、symlink、putenv、exec、shell_exec、chown

执行程序安装

打开绑定的域名，程序会自动检测运行环境是否合格

点击下一步，然后输入数据库以及站点相关信息即会自动安装

至此安装完成

后语

站点目前支持三种鉴黄方式：腾讯云、阿里云、NsfwJs，关于 NSFW API 的安装可以点击链接查看教程。

有关CDN配置可以参考有关这篇 文章

有关站点配置等相关信息，或其他高阶操作可查看官方文档。

前段时间发表了 WebFeed倡议书，倡议书中关于 Feed 类型，推荐所有独立博主都使用 atom，但 WordPress 默认 Feed 类型使用的是 RSS。

关于如何切换为 atom，WordPress官方并没有给出解答，遍寻百度、谷歌等等没有搜索出关于切换 WordPress Feed类型的教程。遍寻WordPress代码终于找到了切换的地方。

切换 Feed 类型

WordPress 在 /wp-includes/feed.php 文件中大约89行处，定义了一个函数——default_feed，仅需将该函数第二个值从默认的 rss 设置为 atom 即可

Feed 类型对照表：

1
2
3
4
5

atom:           $default_feed = apply_filters( 'default_feed', 'atom' );
rss0.92:        $default_feed = apply_filters( 'default_feed', 'rss' );
rss2:           $default_feed = apply_filters( 'default_feed', 'rss2' );

rss 1.0/ rdf:   $default_feed = apply_filters( 'default_feed', 'rdf' );

更改完毕，刷新一下页面即可切换完成。

默认的 RSS 其实也没什么问题，只不过目前各类博客对于 RSS 输出的内容有些混乱，使用 Atom 会使 Feed 更加规范。

什么叫独立博客，独立博客到底该不该开放Feed。

先说说为什么会出现独立博客的概念。一个所谓的“独立”博客个人感觉需要包括三点：

• 拥有一个可供自主解析的二级域
• 大部分文章为博主原创！
• 不依赖于类似 微博、知乎、微信公众号等自媒体平台

由于个人平台输出内容获取的收益无法与此类自媒体平台相比，而且还承担着各种各样的风险以及成本，很多的内容创作者便从个人建站的时代，进入了依赖于第三方平台的自媒体时代，去输出内容。此时独立博客的概念出现，并且由此，独立博客的数量开始走下坡路，但仍有部分博主因为各种各样的原因，依旧保留独立博客。(还有一种说法是不受制于各平台太过于严苛的内容审核机制，仁者见仁智者见智了

第二个问题，独立博客该不该开放Feed。很多独立博客或是因为防止文章被大批量的采集，或是维持网站流量，或是因为各种各样的原因选择关闭了Feed，但这样是对 Web 互联网以及独立博客的概念的影响是非常负面的。

以下内容作者：涛叔

原文地址：https://taoshu.in/webfeed/lets-web-feed.html

为了解决以上部分问题，也为了为了推动开放 Web 生态的发展，涛叔 设计并开发了 WebFeed 扩展。使用 WebFeed，用户可以在浏览器中方便地订阅独立博客，从而获取类似微信公众号的体验。但目前基于 WebFeed (RSS/Atom) 的订阅方案还有不少问题。今天向广大作者发出倡议，希望能一起解决这些问题。

如何方便读者快速订阅博客

我们虽然可以在博客上指明 Feed 链接，但不同博客的链接位置却不尽相同，多数在页面的右上角，少数在页面底部，还有一些在左边或者右边。有的网站虽然提供 Feed 链接，却只在首页等特殊页面展示。如果用户只是阅读某篇特定的文章，则不能第一时间发现 Feed 链接。

为了解决这个问题，我建议所有作者都为博客加入 rss-autodiscovery 支持。简单来说就是在每个页面的<head>部分都添加特殊的<link>标签：

1
2
3
4

<link rel="alternate"
      type="application/atom+xml"
      title="RSS"
      href="https://taoshu.in/feed.xml">

这里的 type 属性指明 Feed 类型。如果是 RSS 需要写成 application/rss+xml，Atom 则需要写成 application/atom+xml。

有了这样标准化的 <link> 标签，我们才有可能实现自动发现、一键订阅等功能。

怎样选择合适的 Feed 类型

我们知道 Feed 分 RSS 和 Atom。虽然 RSS 历史更久远，兼容性更好，我还是建议大家选用 Atom 格式。这是因为在 RSS 规范里面，每一个 <item> 只有一个 <description> 字段。有的站长用它输出摘要，有的站长用它输出全文。局面比较混乱。而 Atom 规范则分别定义了 <summary> 和 <content> ，在语义上更加清晰，客户端在解析的时候也更加简单。

Feed 文件体积过大

很多作者为了方便读者订阅，不但在 Feed 中输出了全文，而且还把所有的历史文章都加到了 Feed 中。这样会生成一个非常大的 XML 文件。Feed 文件体积过大，一方面会消耗不必要的服务器流量，导致下载时间过长，另一方面还会给客户端解析带来非常大的负担。更重要的是，我们不可能在短时间内写很多文章，所以用户订阅 Feed 的时候大多数情况下下载的 XML 文件内容都只有很少变化或者根本没有变化。

为此，我建议各位作者把 Feed 当成一种更新同步机制，而非内容同步机制。也就是说，大家只需要把最新发布的内容输出到 Feed 中就可以了。比如，我们可以只针对最新的十篇文章生成 Feed 文件。读者只需按照一定的周期来检查是否有新的 Feed 就不会错过新发布的文章。为了进一步减少 Feed 文件的体积，我进一步呼吁大家只在 Feed 中输出文章摘要。如果读者有兴趣，则可以作者的博客上继续阅读。

顺便提一个小细节。有的作者为了让读者回源站阅读全文，不但没有在 Feed 中输出全文，而且在输出的摘要的最后还附加了一个超链接，来引导读者跳转到自己的博客。其实这大可不必。因为 Feed 信息中已经包含了文章链接，阅读器一般也都会再显示一个阅读原文按钮。如果在文章摘要中再输出一个，那就会显示两个原文跳转链接，非常难看。

Feed 信息不完善

这个问题基本不影响用户订阅 Feed。但我还是建议作者能把网站标题、网站图标、主页链接、个人邮箱等信息加现 Feed 文件。

统一内容编码

建议大家统一使用 UTF-8 编码。

以上就是我所想到的 Feed 订阅问题。总结一个就是使用 Atom 格式，加入自动发现的 <link> 标签，只输出最新几篇文章的摘要，完善站点信息，比如一使用 UTF-8 编码。欢迎大家留言讨论。也欢迎大家关注WebFeed 项目。

文章原标题：On Unintentional Scams

原文地址：https://www.stephendiehl.com/blog/crypto-scams.html

在此感谢 Mr. Stephen Diehl 的授权。

当然，如果你已经进场 加密货币，或者您就是其中的利益相关者，完全可以不用看这篇文章，它是给没有利益相关并且理性客观的人准备的。

加密货币投资的兴起创造了一个蓬勃发展的的诈骗生态系统。就像化粪池的生态系统一样，现在有一组如此多样的植物群，我们可以开始对金融污水中产生的各种各样的产物进行分类。这样我们或多或少可以分为两个种类：

• 江湖骗子故意实施的诈骗
• 天真的人实施的无意诈骗

自从市场存在以来，我们就已经看到了第一种人，而第二种人在传统上来说是一个非常罕见的。随着不受监管的黑市兴起，它们可能会成为主导互联网金融新世界的那部分。

传销（MLM）计划与加密货币有很多共同点，因为它们是一种企业形式，现金流只包括通过招募更多的新投资者的资金来支付老投资者的利息。传销企业是一种合法的传销方式，在这种方法中，工人从公司自费购买批发产品（化妆品、保健品、维生素等等）然后直接销售给朋友和家人，他们从这些销售中收取少量的佣金。

然而，次要（和绝大多数首要）收入流是通过从同一计划中招募的下级代理那里收取佣金，这些人被称为“线下分销商”。招募人员加入该计划的人可以从他们的销售额中获得一定比例的分成。这种金字塔结构对招聘的激励作用大于销售。如果你招募了四个人来弥补你的损失，那么这四个人必须招募十六个人，那么你就招募了世界上所有卖护肤品的人。数学和经济学在这里根本行不通。

现在大家都知道，把这种事情作为一项工作是非常糟糕的注意。联邦贸易委员会发布了一份关于传销计划经济问题的[报告](https://www.ftc.gov/sites/default/files/documents/public_comments/trade-regulation-rule-disclosure-requirements-and-prohibitions-concerning-business-opportunities-ftc.r511993-00008 /00008-57281.pdf)，不出意料的是，99%的参与者都赔钱。它们是一种掠夺性的财富转移，钱从消息不灵通的人口袋直接被送到了公司高层的口袋里。

同样，加密货币企业使用和销售“产品”的传销公司一样的销售方式销售所谓“代币”。从数学上讲，这就是一场诈骗，它将钱从金字塔中向上输送。大规模的消极的代币投资计划和传销计划只是通过略有不同的机子呈现出相同的现象。然而，由于上世纪80年代的管制和某政府的腐败，决定让这些企业搭便车。许多其他国家干脆直接禁止使用。

关于这些传销活动奇怪的事情是，尽管这些信息在网上广为流传，但是他们还是在大量招募。大多数参与其中的人绝对不符合我们心目中的骗子的样子。他们可能是教堂聚餐会上的普通人，是你的邻居，只是到处兜售这些产品的普通老百姓，他们快乐地四处兜售这些产品，却不知道它们是这个掠夺性系统自我延续的机制。也许他们不是出于恶意，那么纯粹是无知。

这种现象在加密货币的投资中随处可见。狗狗币（Dogecoin，一种模仿比特币的货币）的创造者 Jackson Palmer 表现出了非凡的勇气，他严厉指责了对他帮助发起投资如何变成可怕的东西进行了严厉的控诉。用他的话来说，加密货币是一种“快速致富的崇拜”，旨在“从一无所知的人那里骗钱”。就像传销一样，这就是他的本质。

现在有人认为这是他想要发生的吗？不对，对历史的解读更可能是，一些20多岁的程序员只能通过改变比特币代码库中的几个变量，意外创造了与 Frankenstein’s monster 一样的金字塔计划。现在数以百万计的人因为赌他偶然创造的东西而一无所有，毁掉了自己的生活。

这只是一个例子，彭博社写了一篇尖锐的文章，描述了暴涨暴跌计划的指数级增长，以及每天从公众那里窃取的数十亿美元。在过去的几个月里，Youtube上有一个完整的频道除了揭露有影响力的骗局外什么也没做。他只是发现了冰山一角。Instagram和TikTok背后有数以十亿计的美元，供人们宣传毫无歉意的暴涨暴跌计划以及骗局。就连好莱坞一线明星也加入了这场骗局。

只需要看看 Fyre Festival 灾难，就可以看到每一个加密货币首次发行中都出现过的类似现象。这种现象表现在每一个加密货币的初期阶段。你有一群声名狼藉但充满魅力的人，他们对建立*“结束所有音乐节的豪华音乐节”、“新的 Pied-Piper 开放互联网”或“弗里德里希·哈耶克的自我主权货币愿景”有着宏伟的愿景*. 他们吸纳了越来越多的投资人在招股说明书上投入的资金，然后当他们意识到现实世界存在局限性时，他们就倒下了，这一切都发生了灾难性的变化。这些真正的信徒是骗子吗？这只是故意失明的情况吗？还是他们只是傻瓜？这条线在一定比例下变得非常模糊。

为什么现在这种情况如此普遍？因为如果说加密领域有什么创新的话，那就是它允许世界上任何地方的任何青少年在他们的卧室里发起定制的传销计划，或者在大约5次鼠标点击后进行证券欺诈。再加上完全缺乏监管，我们看到的是，这些人要么没有任何羞耻感，要么因虚无主义的世界观而对欺诈完全不敏感。

腐败和江湖骗子吓不倒我。从文明和商业开始，我们就和它们打交道了。不可否认，金钱甚至会使最有原则的人堕落。然而，更让我害怕的是，基于一种技术的经济体系，这种技术有能力将如此多的好人变成腐败的代理人。加密货币现在是多层次营销的精神继承者，它使同样的人群受害。我们今天在加密市场中看到的，不过是经过变异的传销，以适应全球互联网和社交媒体的美丽新世界。

鸭子测试才是最重要的。如果一个商业模式看起来像传销，像传销一样游动，那么它很可能就是传销。数字签名方案和技术乌托邦主义并不会改变经济状况。商业模式的意图并不重要;通往地狱的道路是由善意铺成的。重要的是结果。

人们经常问我是否认为参与加密的每个人都是骗子。答案是明确的“不”。但对我来说，更可怕的是这么多人可能成为骗局的一部分，甚至不知道。如果我们作为技术人员必须牢记一件事，那就是极其不人道的邪恶是由最幸福的无知的人组成的腐败系统所造成的。