Monthly Archives: January 2026
无限可能的hugging face space
最近刚刚知道一个好玩的东西,就是hugging face的space,可以免费申请使用2vCPU+16GB内存+50GB存储的空间,用来部署你的项目或docker。去主页上看了一下,有不少好玩的应用,比如这个3D相机应用https://huggingface.co/spaces/multimodalart/qwen-image-multiple-angles-3d-camera,允许你调整视角,可以把原来的正面照片改成侧面或背面,也可以改成仰视或俯视。 ↑这是原图。 ↑这是俯视特写图。 ↑这是仰视图。 ↑这是侧视图。 图片还是能看出明显的AI痕迹,不算完美,但可玩度还是很高的。 再比如这个项目:https://huggingface.co/spaces/briaai/BRIA-RMBG-2.0可以抠图,比Windows里的图画程序自带的抠图功能强大多了。 ↑这是原图。 ↑这是抠出来的图。 hf space的服务器都托管在美国Amazon的机房里,速度很快,所以生成这些图片用时都不过几秒到十几秒而已。 期待今后会有更多更好玩的应用出现在hf space上面。
解决问题靠自己
昨天遇到了新问题,就是如何在已经安装并运行了nginx网站的服务器里导入3X-UI面板的问题。问了chatGPT,结果绕来绕去不但没解决,还把chatGPT自己绕进去了。于是只好自己找原因,想办法了。 首先,在已运行 Nginx 并配置好证书的站点安装 3X-UI面板,从理论上说,应该可以让 3X-UI面板直接调用网站的证书,我之前的思路一直是这个,可是新版的 3X-UI面板(v2.8.7)菜单里,根本就没有自己设置证书路径的选项。没办法,只能通过sqlite3 直接写进x-ui.db的数据库里。可写完之后,访问面板根目录依然显示ERR_CONNECTION_CLOSED,看来是nginx的设置有问题。 反复看了nginx的配置文件,没有发现问题出在哪儿。于是只好先洗洗睡了。 今天突然想到了一个变通的方法,既然nginx可以反代给apache,为什么不能也同样反代给3X-UI面板呢?这样统一用nginx监听443端口,网站流量反代给apache,访问面板根目录的流量反代给面板端口,这样面板本身就不用申请SSL了,而又能用SSL安全传输了吗? 想到这里,开始动手写nginx配置文件,先在server块里添加一个location,并且增加^~以调高优先级。 加完之后去访问面板,结果迅速返回404。看了是面板这边根路径没设置造成的,只好sqlite3 x-ui.db进数据库去看一下webBasePath的设定,用 select value from settings where key = ‘webBasePath’; 调取一看,果然是空的,于是update一下,结果还是返回空,看来v2.8.7的设置里没有这一项,只好自己添加了。 再select调取,终于看到根路径了。 返回网页输入https://我的域名/myBasePath/后,3X-UI面板的登录界面终于现身了!
新兵遇到新问题
网上有不少3x-ui的教程,都只是讲怎么在刚申请的新的VPS里安装、使用3x-ui面板,而很少看到如何在一个已经建好的网站、已经申请好证书的情况下导入3x-ui面板。我就遇到了这个问题。网站早就建了,而3x-ui面板是最近才装的,安装的时候让申请证书,结果失败了,因为80端口已经被nginx占了,想着应该可以用之前申请的证书,但却不太清楚如何设置,于是去问了chatGPT,结果就是灾难的开始,查这查那,绕来绕去,最终妥妥地把chatGPT逼得满嘴胡言乱语,问题还是没有解决。看来遇事不决问AI,还是有点于时尚早啊。
找回来了,终于找回来了!
前两天在github上发现了一个好玩意儿,就是S-UI面板https://github.com/alireza0/s-ui。 这玩意儿贼便利!可以说是一键导入多种xray配置,省去你自己写json的麻烦。于是乎赶紧安排上,哦不!是安装上。 装好之后先配置个reality试试吧。哦不!怎么提示443端口被占用呢? 追查了一下元凶,原来是被我这个站点的nginx占用了。 这个好办啊,把nginx停掉就完事儿了。哦不!我这站点还得留着呀! 那咋办好呢?于是去问AI的意见。kimi说可以利用stream层的sni导流,复用443端口。 哇!这个姿势优雅,我来学着摆一个试试! 于是动手安装stream,添加sni配置,这点工作小菜一碟呀,很快就弄完了。 弄完之后发现,哦不!我的网站打不开了!!! 这是咋搞的?就添加了个sni,咋就把网站弄没了呢?! 于是乎开始了和多个AI长达两天的纠错之旅。 AI们也是使出浑身解数,一个问题一个问题的排查,结果愣是查不出原因! AI分析得是头头是道,可网站就是找不回来。 车轱辘话翻来覆去地说了无数遍,就是不能说到点子上。 最后我灵机一动,把建站的来龙去脉跟元宝讲了一通,元宝终于明白了我网站的基本架构: 原来是用nginx作为前端,接受各种请求,如果是网站的请求就反向代理给后端的apache,apache再连接Wordpress打开网页。 了解到这一结构后,问题也就明确了,因为用nginx的stream块做sni分流,但转发的是加密的https流量,而作为后端的apache监听的是8080端口,是没法处理加密流量的。 找到了问题的症结,修起来就容易了。元宝给了我两个建议,一个是还原经典架构,不要用 SNI 分流,这个我不能接受啊!那就第二个吧,什么?让apache配置SSL,处理HTTPS请求,这也忒麻烦了吧。 咦?竟然还有第三条道路!?作为折中方案,元宝建议可以在 Nginx 的 stream 模块中做 SNI 分流,但把流量转发到另一个 Nginx(HTTP 层),这招儿妙哈! 说干就干!先把nginx设置的server块里转发apache的端口改为8081(因为如果不改,端口会冲突),然后去apache的设置文件ports.conf里也把监听端口改为8081,再把apache的VirtualHost 的端口也改为8081。配置好后reload一下apache的服务。 哈哈! 激动人心的时刻来了!我胡汉三又回来啦!
