分类 随手记 下的文章

作者: 未知狐 时间: 2025-5-1 分类: 随手记
值此佳节，祝全球劳动人民节快乐！
picture_2025-05-01_08-11-03.jpg
2025年5月1日 摄于许昌友人家中。

标签: none

已有 5 条评论
mxdyeahmxdyeah
2025年5月2日19:19
老哥是哪里人

回复
未知狐未知狐
2025年5月2日20:29
老家郑州

回复
xfoxxfox
2025年5月2日20:20
中国人。

回复
GoodBoyboyGoodBoyboy
2025年5月1日19:37
狐狐怎么想着爆照了

回复
未知狐未知狐
2025年5月1日19:50
以前直播也一直有露脸吧。

回复

作者: 未知狐 时间: 2025-4-18 分类: 随手记,Linux,趣分享,时间轴,折腾=-=
你是否正在使用沉浸式翻译？或者划词翻译？
前者可以通过开发者模式直接填写使用Deeplx ，而后者则不能直接兼容Deeplx API，需要根据划词翻译的自定义API格式对请求作转换处理，我们这里就使用到了Hcfy-Deepl Translation Adapter完成这一处理过程。

本文的免费原理：Claw Cloud 为注册用户免费提供5美元免费额度，其中Github账户注册时长180天以上的用户还可以每月免费获得5美元免费额度，因此我们可以利用免费额度运行一些资源占用较低的服务，比如：Deeplx及Hcfy-Deepl Translation Adapter
让沉浸式翻译用上Deeplx
仅限Linux.do用户使用：
[喂饭教程] 始皇connect里的DeeplX Key搭配沉浸式翻译
所有用户可用：
首先还是去注册ClawCloud（下面有链接）,位置无所谓，随便选一个地区。
然后在App Store里搜索找到：DeepLX
部署后在App Launchpad -> My APP里找到deeplx-xxxx 项目直接点击进入配置页面
Network(1) -> Public Address 复制下方的DeepLX服务地址公网API访问地址。
该地址不能被划词翻译直接使用，但是可以被其他支持DeeplX API的项目使用。

白嫖Claw Cloud 运行Hcfy-Deepl Translation Adapter 让划词翻译用上Deeplx 翻译！
首先用去注册Claw Cloud
注册完成后跳过用户指引，直接点击 App Launchpad -> Create App 即可。
应用名称 （Application Name） 默认为：hello-world 改为：hcfy-deeplx-bridge
镜像名称 （Image Name） 改为：nerdneils/deeplx_adapter_for_hcfy:latest
接着我们需要调整资源占用降低服务费用到免费额度内。
Usage ：
Replicas 1
CPU 0.1 Core
Memory 64 M
Network：
Container Port ：9911
启用互联网访问(Enable Internet Access) 选项一定要开启。
额外选项 (Advanced Configuration)
环境变量 (Environment Variables): 点击+Add 添加如下内容：
DEEPLX_ENDPOINT 你的DeepLX服务地址一般类似(https://xxx.com/translate）
DEEPLX_NAME deeplx
注意中间空格，随后点击右上角Delpy Application部署应用即可。
然后你就可以得到一个名为hcfy-deeplx-bridge的应用，点进去复制Public Address 下方的公网API地址即可。

安装划词翻译后
进入划词翻译设置页面划词翻译-自定义翻译源
输入我们刚得到的公网API地址，翻译源名称填写：deeplx 并回车。
接着恭喜你完成了所有白嫖过程，现在可以使用浏览器插件通过DeepL翻译任何你想要翻译的内容了！

标签: none

仅有一条评论
EricQwQEricQwQ
2025年4月20日19:31
看到专属还以为是什么会员制社区（吓

回复

作者: 未知狐 时间: 2025-4-17 分类: 随手记,趣分享,时间轴
在隔壁论坛还没到三级注册不了Linux.do邮箱？没关系，Linux用户站也推出了邮箱服务，申请注册零门槛！

申请规则
申请方式如下：

参与Linux用户站稿件投稿（包括重要消息特辑/《内核视界栏目》/本站其他栏目投稿
投稿请发送稿件信息：投稿栏目、标题、作者ID、稿件内容（可以是原文也接受个人站点/cnblog链接，但文章末尾需注明：本文已投稿至Linux用户站）到 [email protected]
也可以加入Linux用户站任意官方交流平台参与投稿。
不接受CSDN等低声誉站点URL投稿！
自由软件开发者认证。
Linux用户站欢迎所有自由软件开发者，认证请提供您的自由软件项目仓库地址。并将您的GPG公钥发送至[email protected]
具体规则以：Linux用户站：邮箱服务为准。

标签: none

已有 2 条评论
GoodBoyboyGoodBoyboy
2025年4月17日20:10
这是自己弄的嘛？

回复
未知狐未知狐
2025年4月17日20:11
不自己来也没人帮我搞啊😭

回复

作者: 未知狐 时间: 2025-4-15 分类: 随手记,趣分享
请看VCR ： steam://rungame/730/76561202255233023/+csgo_download_match%20CSGO-nxpyZ-PwVvE-cJjCt-rCYKK-cwa3K

今天下班剃了近乎光头，然后上号。
各种骚操作，可能剃头真的有特殊Buff

标签: none

仅有一条评论
GoodBoyboyGoodBoyboy
2025年4月17日20:01
小狐狸居然还玩csgo

回复

作者: 未知狐 时间: 2025-4-15 分类: 随手记,Linux,阅读笔记,时间轴,折腾=-=
评论区的广告骚扰涉及毒品广告，包括Github仓库和最终指向暗网的洋葱域名链接，URL是一个.ru域名，评论发送ＩＰ：149.50.116.160。

恶意攻击方面，比如：ＸＳＳ试探攻击。
其中，一个ＩＰ为：38.147.191.215 来自Cogent的HK机房IP
评论内容为 http://xxxxxx/">alert(1)<a/href="#"，其核心目的是通过闭合HTML标签注入JavaScript代码。
不过显然这种低级的漏洞试探对Typecho 1.2.1完全无效。

标签: none

已有 3 条评论
mxdyeahmxdyeah
2025年4月19日17:42
我的discuz站，曾经那被攻击的叫一个惨。一整个板块全是推销内容

回复
未知狐未知狐
2025年4月20日22:39
可怜，除非你非常了解相关技术栈，现在不推荐使用Discuz。

回复
GoodBoyboyGoodBoyboy
2025年4月15日18:13
已阅留爪（逃

回复

作者: 未知狐 时间: 2025-4-14 分类: 随手记,Linux,PHP,折腾=-=
昨天凌晨准备更新文章的时候意外发现Linux用户站后台无法正常登录，点击登录后直接跳转到了主页面。
受限于时间原因，修复工作到了当天晚上下班。
开机后再次在PC上复现BUG 我的第一反应就是反向代理出现了问题，果不其然在网上找到了不少使用CDN后出问题的例子。
Github也有人提出了相关问题，最终解决方案：经过反向代理后，系统没有识别https

sudo nano config.inc.php
添加：

// set ssl
define('__TYPECHO_SECURE__', true);
标签: none

作者: 未知狐 时间: 2025-4-12 分类: 随手记,Linux,时间轴,折腾=-=
书接上回，为了便于使用公网服务器反代内网服务实现内网穿透，我部署了WireGruad，但是连接稳定性无法保证，连接总会在大约一天后断开。因此我想到了之前使用过的内网穿透项目：NPS和Frp，考虑到前者已经失去维护，并且后者的文档也逐渐健全，最终我选择了Frp。
参考文献
获取用户真实 IP —— gofrp.org
Accepting the PROXY Protocol —— Nginx docs

下载FRP
wget https://github.com/fatedier/frp/releases/download/v0.61.2/frp_0.61.2_linux_amd64.tar.gz
xfox@ClawHK:~$ tar -xzvf frp_0.61.2_linux_amd64.tar.gz
frp_0.61.2_linux_amd64/
frp_0.61.2_linux_amd64/LICENSE
frp_0.61.2_linux_amd64/frpc.toml
frp_0.61.2_linux_amd64/frpc
frp_0.61.2_linux_amd64/frps
frp_0.61.2_linux_amd64/frps.toml

cd frp_0.61.2_linux_amd64/
sudo mkdir -p /opt/frp
sudo cp frps /opt/frp/ #部署服务端
sudo cp frpc /opt/frp/ #部署客户端
编写服务端配置
sudo nano /opt/frp/frps.toml

bindPort = 7000
vhostHTTPPort = 8080
auth.token = "your_secure_token"
transport.proxyProtocolVersion = "v2"

编写客户端配置
sudo nano /opt/frp/frpc.toml

serverAddr = "47.242.89.175"
serverPort = 7000
auth.token = "your_secure_token"
[[proxies]]
name = "linuxuser.site"
type = "http"
localPort = 80
customDomains = ["linuxuser.site"]

transport.proxyProtocolVersion = "v2"

[[proxies]]
name = "nas.xfox.fun"
type = "http"
localPort = 5212
customDomains = ["nas.xfox.fun"]
[[proxies]]
name = "ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 22022

关于transport.proxyProtocolVersion = "v2"的配置有一个误区，我应该在需要开启proxy_protocol的对应内网穿透条目[[proxies]]下写这行配置，也就是说上面的配置里如果没有注释也只是为linuxuser.site开启了proxy_protocol支持。
这一问题一度导致我以为nignx配置写错了，自查半天以为自己记忆里的写法有误，最终去问Deepseek浪费了大量时间。

服务/客户端Systemd配置
sudo nano /etc/systemd/system/frps.service
sudo nano /etc/systemd/system/frpc.service

[Unit]

服务名称，可自定义

Description = Frp Server/Client (Self Host)
After = network.target syslog.target
Wants = network.target
[Service]
Type = simple

启动frps的命令，需修改为您的frps的安装路径

ExecStart = /opt/frp/frps -c /opt/frp/frps.toml

启动frpc的命令，需修改为您的frpc的安装路径

ExecStart = /opt/frp/frpc -c /opt/frp/frpc.toml
[Install]
WantedBy = multi-user.target

运行客户端/服务端
sudo systemctl enable frpc.service --now
sudo systemctl enable frps.service --now

Nginx反向代理

/etc/nginx/sites-enabled/linuxuser.site

server {

listen 80;
server_name 127.0.0.1 linuxuser.site www.linuxuser.site;
root /ZHITAIPC005/www/linuxuser.site;
index index.php index.html index.htm;
client_max_body_size 128m;

# 真实IP解析（信任前端代理）
    # /etc/nginx/conf.d/frp_real_ip.conf
# Typecho URL重写规则
location / {
    try_files $uri $uri/ /index.php$is_args$args;
}

# PHP处理配置
location ~ \.php$ {
    fastcgi_param HTTP_X_FORWARDED_FOR $http_x_forwarded_for;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_index index.php;
    include fastcgi.conf;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

# 日志配置
access_log /ZHITAIPC005/www/log/linuxuser.site.access.log frp_real_ip;
error_log /ZHITAIPC005/www/log/linuxuser.site.error.log;

}

这里也有个坑：Nginx的日志指令中，access_log的语法是：

access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition];

而error_log的语法是：
error_log file [level];
所以不能在error_log也写上frp_real_ip，否则frp_real_ip会成为一个无效的错误日志等级。
至于上面提到的frp_real_ip这个log_format，必须位于nginx.conf的http块中，但是考虑到nginx是可能随着Debian13的发布更新版本因此/etc/nginx/nginx.conf可能在更新时被覆盖写入。我们应该采取更规范的额外配置引入方式：
sudo nano /etc/nginx/conf.d/frp_real_ip.conf

/etc/nginx/conf.d/frp_real_ip.conf
定义日志格式（必须在http块内）
使用proxy_protocol
log_format frp_real_ip '$proxy_protocol_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';
set_real_ip_from 47.242.89.175;
set_real_ip_from 127.0.0.1;
real_ip_header proxy_protocol; # 从 Proxy Protocol 数据中提取真实 IP
使用X-Forwarded-For
log_format frp_real_ip '$http_x_forwarded_for - $remote_user [$time_local] '

             '"$request" $status $body_bytes_sent '
             '"$http_referer" "$http_user_agent"';

可选：配置信任的代理IP（若使用Real IP模块）
set_real_ip_from 47.242.89.175;
set_real_ip_from 127.0.0.1;
real_ip_header X-Forwarded-For;

这里还有一个小问题，你不能画蛇添足的给log_format外再套一个http{}块。
查看/etc/nginx/nginx.conf发现

http{
...其他配置
include /etc/nginx/conf.d/*.conf;
...Other confg
}
也就是说/etc/nginx/conf.d/*.conf的配置默认就是在http块内引入的，所以不能画蛇添足的给log_format外再套一个http{}块。

前端服务器配置
我上面用到了$http_x_forwarded_for这个变量，如果客户端或上游代理已经添加了 X-Forwarded-For 头，Nginx 作为反向代理时默认会将其传递给后端服务器。
但需注意：如果 Nginx 是第一个代理（直接接收客户端请求），默认不会主动添加 X-Forwarded-For 头，除非显式配置。
所以在前端服务器，也就是我的公网服务器必须手动指定Nginx向后传递X-Forwarded-For 头。
以下就是linuxuser.site的最前端服务器配置

server {

listen [::]:443 ssl http2;
listen 443 ssl http2;
server_name linuxuser.site www.linuxuser.site;

SSL证书路径（保持用户原有配置）

ssl_certificate      /home/xfox/www/all_linuxuser.site/fullchain.pem;
ssl_certificate_key  /home/xfox/www/all_linuxuser.site/privkey.pem;

# SSL优化配置
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;

root /ZHITAIPC005/www/linuxuser.site;
index index.php index.html index.htm;
client_max_body_size 128m;

# 反向代理配置
location / {
    proxy_pass http://linuxuser.site:8080;
    proxy_set_header X-Forwarded-For $remote_addr;
    # 保留必要头部（供FRP识别）
   proxy_set_header Host $host;

}


# 其他通用配置

# access_log /var/log/nginx/linuxuser.site.access.log;
# error_log /var/log/nginx/linuxuser.site.error.log;
}

查看效果
通过上面的一系列配置，我已经实现了通过X-Forwarded-For将访客IP 按照：
HK Server -> FRP -> Home Server 的完整链路传输
现在在Home Server执行 tail -f /ZHITAIPC005/www/log/linuxuser.site.access.log
再访问https://linuxuser.site/ 即可检验成果。

使用体验
感觉比使用WireGruad组网再反代的Web资源响应速度好了很多啊，nas的图片预览刷新明显更快了。

总结
今天的一番折腾更加坚定了我“不能完全依赖AI进行方案设计”的理念，使用AI要尽可能保证自己对达成目标所涉及的技术栈的基本原理框架有清晰认知。 大语言模型非常适合替代搜索引擎帮助用户高效检索信息，但是绝对不能用来替代你的逻辑思考过程，否则你会成为AI的奴隶，原本要完成的目标也在AI的幻觉迷惑下变得模糊不清，即使最终解决了问题也浪费了大量时间。

今天实际应用成功的Nginx 公网反代真实IP获取这一完整方案并非AI所推荐给我的。
Ai生成的方案存在肉眼可见的不和谐，比如端口冲突，没有考虑到Nginx 的http模块只能接收proxy_protocol而无法向后端发送proxy_protocol 导致后端只能接收到HK Server的公网IP。
还有诸多谬误，我不再一一记录，总而言之：不要偷懒让AI独自完成方案思考，用户必须有基于已知知识建立自己的主见。使用AI过程中出现的新知识点以及不了解的细节一定要及时查阅官方文档或者问AI。

标签: none

已有 2 条评论
GoodBoyboyGoodBoyboy
2025年4月12日20:30
终于还是用上了TCP（doge

回复
未知狐未知狐
2025年4月13日0:55
我还没写完文章你就评论了。😭

回复

作者: 未知狐 时间: 2025-4-6 分类: 随手记,阅读笔记,时间轴
众所周知，我的站点网络拓扑主要包含了：

代号 名称 IDC 网络环境
A 公有服务器 香港阿里云 公网IPv4+公网IPv6
B 家庭服务器 中国联通 NAT后IPv4+公网IPv6
A、B通过WireGuard组网连接，除了本博客和Mumble，其他服务均通过公网A进行反代->WG内网转发->私有服务器B
经过一段时间的测试，我可以确定郑州联通确实存在UDP控制。最近的一次WG掉线后（也就是昨天通过NAS公网转发备份了大约11GB的图片后），备份完成WG是没有掉线的，但是今天下午我发现掉线了。
立即重启WG检查了A/B的收发数据发现：
A没有明显异常，但是接收数据偏少。
B发送数据没有问题，接收数据直接0了。
显然，联通禁止了从A->B的UDP流量，这一情况是基于IPv4环境下的。在我将WG配置的端点地址改为域名后，AB自动使用IPv6完成了组网。
未来我会继续在这个帖子更新WG使用过程中发现的运营商UDP QoS相关问题。

连接再次中断
xfox@EliteDesk800G3:~$ sudo wg
[sudo] xfox 的密码：
interface: wg0
public key: voB153oa0vHHuPpA2cCAb3diJ2iQr7WyiqCYadqNV3U=
private key: (hidden)
listening port: 54343

peer: ol49XfUIm1dCcxr5SyD+AFl+b9LSI5tab7YOKo6kPQQ=
endpoint: [240b:4001:278:8401:ffff:abb0:2987:aa04]:51820
allowed ips: 10.10.0.1/32
latest handshake: 1 day, 17 hours, 20 minutes, 3 seconds ago
transfer: 4.31 MiB received, 74.84 MiB sent
persistent keepalive: every 25 seconds
可以发现，连接实际上很不稳定。
因为中断时间间隔很短。
看来我必须考虑tcp连接完成组网了。
作为临时措施，我先调整端口到53,并恢复使用ipv4，同时调整keepalive 从25到2s
4月11日4：23分更新：
根据wg输出的上次握手时间，2025年4月10日18时
连接断开了。显然简单的调整端口和缩短心跳时间并不会有助于维持稳定的wg组网。
看来我必须得试试使用FRP实现反代了。

标签: none

已有 4 条评论
kooriteakooritea
2025年4月8日11:33
跨境用wg这种太容易被墙或者qos了，就算是境内udp也容易qos，套个常见的代理协议会好很多。

回复
未知狐未知狐
2025年4月8日17:44
墙是目前没墙，代理协议是万万不敢套的。

回复
GoodBoyboyGoodBoyboy
2025年4月7日20:42
哈哈哈我说过了，国内玩UDP被运营商Qos就老实了（doge

回复
未知狐未知狐
2025年4月8日7:31
🫠那也要玩.....TCP组网大概率直接被当某种正向代理ban 了。

  1. 1
  2. ...
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. ...
  11. 47