包含关键字 PHP 的文章

你可能已经发现我的Mastodon上刷了一大串帖子,这正是刚才测试文章同步造成的。

同步使用了项目:FediverseSyncForTypecho 原始仓库为:jkjoy——FediverseSyncForTypecho
原仓库不支持使用代理完成网络请求,使得该插件在某些Mastodon站点被GFW屏蔽的情况下完全无法使用。
我的仓库把Release版本号刷到了1.6.5 主要增加了对http和socks5代理的支持。也是顺便测试借助DeepSeek 彻彻底底Vibe Coding了一回,确实很方便,花小钱办大事,比自己慢慢扣效率高太多了。

本次Vibe Coding使用Visual Studio Code搭配DeepSeek V4 for Copilot Chat

这个项目我自从看到GS在用就注意到了,当时就下载测试发现不支持代理试图自己添加代理支持(简单写死的)可惜学艺不精没一直扣完,太简陋不想公开最终拖到了今天。
我已经尽自己所能的审查了AI生成的代码,但是为了避免Vibe Coding可能潜在的混乱和污染问题,这个仓库的更新我不会推送到原始仓库,就让本项目作为我的个人试验品好了

具体更新如下:

Fediverse Sync for Typecho - 更新日志

版本 1.6.5 (2026-06-18)

新增功能

  • SOCKS5/HTTP 代理支持

    • 新增可选代理配置,支持 HTTP 和 SOCKS5 两种代理类型
    • SOCKS5 使用远端 DNS 解析(CURLPROXY_SOCKS5_HOSTNAME),避免 DNS 污染
    • 支持代理认证(用户名/密码)
    • 适用于中国大陆等网络受限环境

重构优化

  • HTTP 请求统一重构

    • 将分散在 Plugin.php、Action.php、Api/Sync.php 中的 6 处原始 cURL 调用集中到 Utils/Http.php
    • 新增 postForm() 方法,统一处理 Mastodon/GoToSocial 的表单编码 POST 请求
    • Header 去重处理,避免重复 header 导致 400 错误
    • 代理逻辑由 Utils/Proxy.php 集中管理,一处配置全局生效

调试改进

  • 增强 HTTP 层错误日志

    • 请求失败时自动记录 URL、HTTP 状态码、cURL 错误号和错误描述、响应体预览
    • Proxy 应用代理时记录代理类型和地址,便于确认代理是否生效

文件结构

FediverseSync/
├── Utils/
│   ├── Proxy.php           # 增强:支持 SOCKS5+HTTP 代理类型选择
│   └── Http.php            # 增强:新增 postForm() + 代理集成 + 日志增强
└── Plugin.php              # 新增5个代理配置项

这是自以来2023年六月六日1.2.1更新以来的又一次更新!
全部更新内容参考:
https://github.com/typecho/typecho/compare/v1.2.1...v1.3.0

Typecho v1.3.0 是一个以修复安全和稳定性问题为主的版本,同时包含了一系列的功能改进、性能优化和代码清理。它加强了对现代 PHP 环境的支持(PHP 7.4+),并整合了活跃社区的多项贡献。
理论上,升级此版本将获得更安全、更稳定、体验更好的博客系统。建议所有博友都及时升级。

2026年2月9日

已经完成升级。

厂商型号:YR-CP100
主板版本:CP102-MAIN-V2.2
主要芯片:RG200U-CN V3MF-D10-DDC(移远通信)
其他硬件:塑料外壳,3根FPC天线(疑似5G/4G),2根WIFI天线。1个USB Type-C 接口,1个RJ45网线接口。
开盖后取下主板风扇可见各个模块及2个SIM芯片(预计为移动和电信)还有一个空SIM芯片引脚,以及一个没有引出接线位置的SIM卡槽标识位置。

固件备份

经过不懈努力终于在一众工具中找到了我能正常使用的备份工具。
除了spd_dump是可用的,还有SPRDC_Core也是可用的。但是这两个工具对本设备仍然有一些概率性的玄学问题,比如莫名其妙的信号灯超时时间已到报错。
备份分区表:

<?xml version="1.0" encoding="utf-8"?>
<Partitions>
  <Partition id="prodnv" size="4" />
  <Partition id="miscdata" size="1" />
  <Partition id="recovery" size="16" />
  <Partition id="misc" size="1" />
  <Partition id="trustos" size="1" />
  <Partition id="sml" size="1" />
  <Partition id="uboot" size="2" />
  <Partition id="boot" size="16" />
  <Partition id="system" size="53" />
  <Partition id="userdata" size="0xFFFFFFFF" />
  <Partition id="nr_fixnv2" size="6" />
  <Partition id="nr_runtimenv2" size="9" />
  <Partition id="nr_pmsys" size="1" />
  <Partition id="nr_agdsp" size="6" />
  <Partition id="nr_modem" size="27" />
  <Partition id="nr_v3phy" size="6" />
  <Partition id="nr_nrphy" size="3" />
  <Partition id="nr_nrdsp1" size="2" />
  <Partition id="nr_nrdsp2" size="2" />
  <Partition id="nr_deltanv" size="1" />
  <Partition id="ubipac" size="248" />
</Partitions>

这个东西的价格和性能符合我的预期,到的第一天内置移动卡5G测速150Mbps下 50Mbps上,不过这个WI-FI性能就比较怪异了,特别是延迟极端的不稳定,插线用倒是完全没问题,跟手机USB网络共享的热点延迟一致。

简单逆向分析

通过hexdump查看分区镜像文件数据头部的魔数(Magic Number)为:DHTB
xfox@fedora:~/Dev/YR-CP100$ hexdump /home/xfox/Dev/YR-CP100/all_part_backup/system_payload.bin -C | head -5
00000000 44 48 54 42 01 00 00 00 00 00 00 00 00 00 00 00 |DHTB............|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000030 00 2e df 01 00 00 00 00 00 2e df 01 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
查询相关资料可以确定这是紫光展锐设备特有的DHTB分区格式Dynamic Hybrid Trusted Boot,根据已有信息,DHTB分区会把原始分区放置在DHTB数据头后。
直接使用ImHex编辑器查看整个system.img发现0x1000处出现了68 73 71 73 -> hsqs字样。
结合DS对hexdump回显的前几十行原始数据的分析:

根据你之前 hexdump 的结果:
在 0x30 处的值 00 2e df 01 (小端序为 0x01df2e00,约30MB) 很可能指示了**某个数据段的长度。**
在 0x1000 处出现了 68 73 71 73 (hsqs),这很可能是**一个有效数据块的起始标志**,但它不是UBI格式。
因此,你的 system.img 结构很可能如下:
偏移量 0x0:    DHTB 文件头 (包含长度等信息)
偏移量 0x1000:  某个数据块开始 (可能是压缩的映像,如 squashfs)

所以确定原始分区是一个基于Linux的SquashFS只读压缩文件系统,通过dd命令取出原始分区:
dd if=system.img of=system_payload.bin bs=4096 skip=1
SquashFS分区镜像可以直接挂载。

确定架构

cat /etc/os-release
ID=unisoc-initgc
NAME="unisoc-initgc-distro"
VERSION="udx710-module+unisoc-initgc-1.0+W25.38.5:10.52.14+user+native (sumo)"
VERSION_ID=udx710-module-unisoc-initgc-1.0-w25.38.5:10.52.14-user-native
PRETTY_NAME="unisoc-initgc-distro udx710-module+unisoc-initgc-1.0+W25.38.5:10.52.14+user+native (sumo)"
DISTRO_CODENAME="sumo"

从Yocto sumo的时间点看貌似是2018年的老版本了,Linux Kernel 4.14.98估计是厂商提供给开发者的SDK。
比较有趣的是,解包后里面开发者写的后台PHP代码基本上和安全俩字没什么关系,连我这个纯外行都能看出来有明显的漏洞,群友们表示尝试过修改镜像并刷回但是因为没有厂商提供的证书签名启动不了。
所以后续Crack完全没必要改来改去硬刷镜像,理论上可以通过Web渗透完成既定目的。

2026年1月26日,Got Shell!

昨天通过对后台PHP代码的查看确定了后台处于不设防的状态:

    function quoteArgument($value) {
        return empty($value) ? "'null'" : "'{$value}'";
    }

    function quoteArgument_int($value) {
        return empty($value) ? "0" : "'{$value}'";
    }

    function execShell ($cmd) {
        $result = shell_exec($cmd);
        $json = json_decode($result);

        if ($json->result === 0)
            return "success";
        else
            return "error";
    }

今天一通尝试,终于构造了post请求拿下了root shell,看/usr/bin有adbd看起来可以启用adbd.
/etc/init.d/下发现了adbd-init 当然,默认是没启用。

2026年1月27日

扒拉到/etc/usbenum/usbenum.ini

[machine]
machine=udx710-module
[property]
virtualcn=0
diag=1
log=1
debug=1
usbch=mode0
iq_vser=close
udc=29100000.dwc3
afterpowerloss=1
#virtualcn 0-rndis|1-ecm|2-ncm|3-mbim|4-8*AT|5-1*ecm|6-2*ecm|7-3*ecm|8-4*ecm|9-1*ncm|10-2*ncm|11-3*ncm|12-4*ncm|13-test

看上去我完全有机会使用USB cdc-ncm 替换RDNIS,当然...前提是能修改好镜像。
似乎可以通过overlay完成对SquashFS的写入存储?但是一改/etc/fstab就涉及现有鸡还是现有蛋的问题了,早于系统启动之前完成修改是不可能的,最终还是得诉诸于修改和重新打包刷入system镜像。

前段时间我去爬山,回来写了文章:朱雀国家森林公园痛苦一日游
上传图片的时候发现当前时代的浏览器并不支持浏览HEIF格式的图片,但是这一标准在苹果和许多较新安卓设备上都已经开始推广,并且压缩率不错,所以能不能想办法让浏览器显示HEIF格式的图片呢?

找到所需开源项目:

hoppergee/heic-to Convert HEIC/HEIF images to JPEG, PNG in browser
我的需求显然早就有人在做了,这个项目利用javascript提供了一个在前端将HEIF格式图片转换成jpeg/png的方案。

引用heic-to

工作原理:

  1. 自动检测所有带有.heic或.HEIC扩展名的图片
  2. 使用fetch API获取原始HEIC文件
  3. 在浏览器中转换为JPEG格式
  4. 替换图片的src属性显示转换后的图片
<script type="module">
// 导入CSP安全版本的HEIC转换模块 需要支持ES6特性
import { heicTo } from 'https://cdn.jsdelivr.net/npm/[email protected]/dist/csp/heic-to.js';

document.addEventListener('DOMContentLoaded', async function() {
    // 检查浏览器是否支持所需API
    if (!window.fetch || !window.URL || !window.Blob) {
        console.warn('浏览器不支持HEIC转换所需API');
        return;
    }
    
    // 处理HEIC图片转换
    async function processHEICImages() {
        const images = document.querySelectorAll('img[src$=".heic"], img[src$=".HEIC"]');
        if (images.length === 0) return;
        
        console.log(`找到 ${images.length} 张HEIC图片,开始转换...`);
        
        for (const img of images) {
            const src = img.src;
            const originalAlt = img.alt || '';
            const originalClass = img.className;
            
            try {
                // 添加加载状态
                img.alt = 'HEIC图片转换中...';
                img.classList.add('heic-loading');
                
                // 获取HEIC文件
                const response = await fetch(src);
                if (!response.ok) throw new Error(`HTTP错误! 状态码: ${response.status}`);
                
                const blob = await response.blob();
                
                // 转换为JPEG
                const jpegBlob = await heicTo({
                    blob: blob,
                    type: "image/jpeg",
                    quality: 0.8
                });
                
                // 创建对象URL并替换
                const jpegUrl = URL.createObjectURL(jpegBlob);
                img.onload = function() {
                    URL.revokeObjectURL(jpegUrl); // 释放内存
                    img.classList.remove('heic-loading');
                    img.classList.add('heic-converted');
                };
                img.src = jpegUrl;
                img.alt = originalAlt;
                img.className = originalClass;

            } catch (err) {
                console.error('HEIC转换失败:', err);
                img.alt = originalAlt + ' [HEIC转换失败]';
                img.classList.remove('heic-loading');
                img.classList.add('heic-error');
            }
        }
    }
    
    await processHEICImages();
});
</script>

<style>
.heic-loading {
    position: relative;
    min-height: 100px;
    background: #f5f5f5 url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"><circle cx="50" cy="50" r="40" stroke="%233498db" stroke-width="8" fill="none" stroke-dasharray="62.8 188.8"><animateTransform attributeName="transform" type="rotate" repeatCount="indefinite" dur="1s" values="0 50 50;360 50 50" keyTimes="0;1"></animateTransform></circle></svg>') no-repeat center;
    background-size: 50px;
}
.heic-converted {
    border: 2px solid #2ecc71;
}
.heic-error {
    border: 2px dashed #e74c3c;
}
</style>

使用方法:

你可以引用上面的代码到任意html页面,通常我们把他放在header或footer里。
在Typecho上我们可以把它放在主题文件的: header.php 中

本文代码已在Github以MIT协议开源,感谢自由软件与开源社区!
DisplayMyHEIC

测试图片

测试图片1-人物
测试图片2-缆车

作者: 未知狐 时间: 2025-6-30 分类: 随手记,Linux,折腾=-= 2 条评论
参考:
修正linux下wayland的chrome輸入與顯示錯誤
无法在Chrome(Wayland)中使用fcitx5
Wayland下使用UseOzonePlatform无法显示界面 #2300
support IME under native Wayland #33662
Vscode does not launch in wayland session #146349
Ozone-wayland: support text_input_v3 protocol

Chromium从98版本开始已经默认支持Wayland,用户可以通过--ozone-platform-hint=auto参数启用Wayland支持。问题根源在于 Chromium对Wayland的兼容措施还没有完全释出, text-input-v3 支持虽然已经合并但因为前者还存在一些问题。
2025-06-29T19:56:53.png
作为对wayland支持的努力,UseOzonePlatform现在是 chrome://flags/#ozon-platform-hint 中的一个实验性选项,默认没有启用。
启用后选择auto即可,但是理论上应该确保XDG_RUNTIME_DIR 和 WAYLAND_DISPLAY 等环境变量正常传递,这可能影响Chromium对当前运行环境的识别,
终端执行 echo $XDG_RUNTIME_DIR 和 echo $WAYLAND_DISPLAY,正常应返回类似 /run/user/1000 和 wayland-0 的路径。
查找资料过程中发现用户使用--ozone-platform-hint=wayland 后只有第一次重新启动是正常的,第二次就无法启动
我的终端里可以看到刷屏的报错:

[10091:10136:0630/034118.878942:ERROR:gpu/command_buffer/client/client_shared_image.cc:133] Failed to map the buffer.
[10091:10136:0630/034118.878946:ERROR:gpu/command_buffer/client/client_shared_image.cc:231] ScopedMapping init failed.
[10091:10136:0630/034118.878951:ERROR:gpu/command_buffer/client/client_shared_image.cc:431] Unable to create ScopedMapping
[10091:10136:0630/034118.878957:ERROR:cc/raster/one_copy_raster_buffer_provider.cc:303] MapSharedImage Failed.
[10091:10136:0630/034118.878964:ERROR:ui/gfx/linux/client_native_pixmap_dmabuf.cc:49] Failed to mmap dmabuf: 权限不够 (13)
丢给Deepseek分析:
根据您提供的错误日志,问题核心在于 Chromium 在 Wayland 环境下尝试使用 DMA-BUF 共享内存时出现权限问题,导致 GPU 进程初始化失败。以下是针对性的解决方案:
内容已丢失

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

回复

本文是对计划表中:基于人工+AI的开源与自由软件和科技采集发布,旨在复刻老王叔叔的linux.cn模式 的具体实践。

确定域名

昨天晚上,我买下了一个新域名:linuxuser.site 寓意:“linux用户站
为什么是用户/User而不是“粉丝/Fans”或者“玩家”呢?
我认为“用户”一词是最普遍的,最能囊括受众群体的。

服务部署

同一时间,我在本地部署了“linux用户站”的web服务器,和本博客相同的typecho。也算是一种路径依赖吧,我已经很难接受WP那种臃肿的PHP应用,这次的部署与之前有所不同,我没有使用MySQL/MariaDB而是选择了SQLite。
现在你可以访问https://linuxuser.site 查看这个简陋的站点。

现状与未来

国内有许多人,特别是年轻人对Linux的印象还停留在:黑客之选、极客玩具、普通人用不了、必须用命令行 这样的刻板印象。
除此之外,还有许多人虽然每天在互联网上把Linux挂在嘴边,频繁浏览相关视频,频繁发布相关评论,却从不在实际生产生活中使用Linux内核和各种Linux发行版。这种人在互联网上有一个很贴切的新名词:云玩家

搭建这个站点,既是为了圆我曾经对自由软件和开源的一腔热血,也是为了做点公益,冲淡充斥互联网的低质量口水文章,给希望以及正在使用Linux发行版的朋友们指引方向。
这个站点的建设也与linux.cn停运有着不可割舍的关系,在我看来老王叔叔是一个值得敬佩的Linux传道者,linux中国的文章也一度惠及我和身边的朋友,搭建这个站点亦有复刻Linux中国复活社区的意味。也许不久的将来我们有机会重现一个新的炎黄角马。

站点的收支

目前来看,我完全有能力自己承担域名和服务器的基本运维。甚至有余力时不时发点文章或者科普,在站点规模持续扩大超出作为我的业余爱好的对应资费水平之前,我不打算给服务器添加任何广告。我也不打算把站点打造成一个盈利工具,站点的一切收入会全部投入站点运营本身。如果侥幸有所盈余,就捐给联合国儿童基金会吧。