作者: 未知狐 时间: 2025-6-13 分类: 随手记,Linux,折腾=-= 1 条评论
具体报错：
Could not create collection trash, resourceId 4
2025-06-13T13:54:51.png

解决方案
SOLVED - KMAIL refuses to launch

rm -rf .local/share/local-mail/trash/

作者: 未知狐 时间: 2025-6-9 分类: 随手记,Linux,折腾=-= 评论
使用公共服务：http://udp.xnkiot.com/ 在此感谢该公益服务提供者。

Python 跨平台测试示例

import socket

创建一个 UDP socket

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

发送数据

message = b'Hello, UDPQwQ'
sock.sendto(message, ('8.135.10.183', 53093))

关闭 socket

sock.close()
为什么有这个测试？
那就...得问某个喜欢女装的港仔了。

尝试解决笔记本麦克风噪音问题
作者: 未知狐 时间: 2025-5-10 分类: 随手记,Linux,时间轴,折腾=-=
我正在使用机械革命的设备，有得必有失，便宜的价格意味着某些硬件性能的阉割————比如糟糕的麦克风拾音效果。这主要是因为散热风扇的巨大底噪导致的。

好在，要解决这个问题理论上还不算太困难，语音降噪技术已经相当成熟，我们有许多降噪方案可以选择。
这次我打算试试NoiseTorch这个项目，如果部署体验一段时间后效果不错，我将会在Linux用户站同步更新部署方案。

尝试部署
从Github下载最新的二进制预编译程序，截至目前是v0.12.2
压缩包的结构如下：
2025-05-10T13:11:04.png

在压缩包所在目录执行：
tar -C $HOME -h -xzf NoiseTorch_x64_v0.12.2.tgz
此时desktop等文件应该已经位于正确的位置了，接着刷新桌面环境缓存使其正常显示在应用列表。
对于KDE用户：

kbuildsycoca5 --noincremental # KDE5

kbuildsycoca6 --noincremental # KDE6
对于Gnome用户：

gtk-update-icon-cache

在菜单搜索noise即可找到：
2025-05-10T13:39:40.png

你可能会看到如下窗口：
2025-05-10T13:42:04.png

窗口提示你 NoiseTorch 当前无法正常运行，因为它需要 CAP_SYS_RESOURCE 权限（一种 Linux 系统的高级权限）。如果你不了解此权限，可以点击下方的 “Grant capability (requires root)” 按钮，程序会尝试自动获取权限（需要输入 root 密码）。
如果你没有使用常见的桌面环境，可以手动执行命令授权：
sudo setcap cap_sys_resource+ep /home/$USER/.local/bin/noisetorch
如果你通过点击完成了授权，程序将在授权后自动重启，你会看到类似下图的窗口：
2025-05-10T13:59:46.png

默认开启了对麦克风的噪音过滤，你需要选择正确的PC麦克风设备（我的是Family 17h/19h/lah HD Audio Controller）并点击Load NoiseTorch
接下来，你会发现音频管理器里 多了一个输入设备：
NoiseTorch Microphone for Family 17h/19h/lah HD Audio Controller
随后，你可以在需要麦克风的设备中选择使用该设备即可实现麦克风降噪输入。
2025-05-10T14:05:02.png

效果体验：
坦白来说，效果不太理想。但是...这貌似不是因为软件导致的，因为我的麦克风真的是太烂了，我感觉他明显受到了某些电磁/震动干扰。或者说，我买回来的时候这玩意压根就是损坏的状态。
通过Audacity录音测试，我感觉是从完全不可用的状态到了很炸但是能听见人声的状态。
具体效果有待上游戏验证。录音太炸裂就不放了。
其实，就算用不了我也可以用MT6 Pro的麦克风，而且这个自带ENC降噪

关于翻译和打包问题
根据internalisation i18n，尽管项目目前还没有正式的支持多语言，但是显然社区都很乐意提供翻译支持，后续我可能会尝试fork 并提交第一个简体中文版本。
其次是有必要的话直接对项目进行打包生成便于安装部署的deb/rpm软件包。

作者: 未知狐 时间: 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 分类: 随手记,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
我还没写完文章你就评论了。😭

回复