Nginx Proxy Manager修复笔记

Edited on In Views: Reading time ≈ 18 mins.
排查Nginx Proxy Manager，反向代理，让网站变成HTTPS

有什么用

排查Nginx Proxy Manager，反向代理，让网站变成HTTPS

实现方法

Nginx Proxy Manager 登录异常
http://192.168.6.116:881/login

11am NPM, 登录失败错误：Bad Gateway
    template-db-1	已停止	jc21/mariadb-aria:latest	
发现是附属的docker的"/template-db-1" 启动失败
- 修复？

2023-11-03  3:13:28 0 [Note] /usr/bin/mysqld (mysqld 10.4.15-MariaDB) starting as process 1 ...
2023-11-03  3:13:28 0 [ERROR] mysqld: Can't create/write to file '/var/lib/mysql/aria_log_control' (Errcode: 13 "Permission denied")
2023-11-03  3:13:28 0 [ERROR] mysqld: Got error 'Can't create file' when trying to use aria control file '/var/lib/mysql/aria_log_control'
2023-11-03  3:13:28 0 [ERROR] Plugin 'Aria' init function returned error.
2023-11-03  3:13:28 0 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
2023-11-03  3:13:28 0 [Note] Plugin 'InnoDB' is disabled.
2023-11-03  3:13:28 0 [Note] Plugin 'FEEDBACK' is disabled.
2023-11-03  3:13:28 0 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2023-11-03  3:13:28 0 [ERROR] Failed to initialize plugins.
2023-11-03  3:13:28 0 [ERROR] Aborting

可能是从因为Nginx Proxy Manager是通过docker-compose来运行的，断电重启以后，docker无法自动正确地按docker-compose来启动了。
解决办法是
1. 关闭这个两个docker容器（jc21/nginx-proxy-manager:latest	和 jc21/mariadb-aria:latest）
2. SSH去执行
    # cd /www/server/panel/data/compose/NginxPorxyManager/template
    # docker-compose up -d
这就意味着以后，以后机器重启，都要去手动去执行这docker-compose，有没有更好的解决办法？
解决了docker启动，登录NPM还是提示：Bad Gateway错误
检查了docker ps，依旧Restarting (1) 28 seconds ago  template-db-1

2:20pm
Docker 具体错误

1
2
3
4
5
6
7
template-db-1   | 2023-11-03  6:20:19 0 [ERROR] Plugin 'Aria' init function returned error.
template-db-1   | 2023-11-03  6:20:19 0 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
template-db-1   | 2023-11-03  6:20:19 0 [Note] Plugin 'InnoDB' is disabled.
template-db-1   | 2023-11-03  6:20:19 0 [Note] Plugin 'FEEDBACK' is disabled.
template-db-1   | 2023-11-03  6:20:19 0 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
template-db-1   | 2023-11-03  6:20:19 0 [ERROR] Failed to initialize plugins.
template-db-1   | 2023-11-03  6:20:19 0 [ERROR] Aborting

最后方案：放弃视频‘推荐’的方案，改用默认的sqlite.

4:46pm NPM
改了配置以后，服务都正常了；可是新的配置在UI上没有加载之前的的配置内容。
不配置maradb db section, NPM会自己在保存在./data目录下面一个database.sqlite文件数据库。
5:10pm Cloudflare API token 重新配置
dns_cloudflare_api_token e385e19ce47c207b15bf@@@@@
重新申请证书，用DNS challenge的方式。 

接下来，新的反代的就直接去新建就好了（待验证）
》5:17pm

安装目录：/www/server/panel/data/compose/NginxPorxyManager/template

如何编辑artalk的robots.txt

收到Google的邮件（New reason preventing your pages from being indexed）
第二天根据链接里面的indexing report，转到问题的问题；之前还去主站点位置添加的www.carlzeng.com/robots.txt.
原来是报告https://artalk.carlzeng.com:4443/robots.txt 这个页面下的。

在artalk容器以及映射出来的目录找了半天也找不到这个文件，莫非是程序动态生成的（无解了？）
也可能是NPM的反代有这样的设置?
https://www.iots.vip/post/hexo-artalk-comment.html

在BT中，/www/server/phpmyadmin/phpmyadmin_c123@@/目录下，搜索到了robots.txt, 修改内容为：
User-agent: *
Allow: /
继续访问https://artalk.carlzeng.com:4443/robots.txt；仍然无效
尝试修改NPM中关于artalk反代的nginx配置文件，参考博客样式
location =/robots.txt {
default_type text/html;
add_header Content-Type “text/plain; charset=UTF-8”;
return 200 “User-Agent: \nAllow: /“;
}

12:56pm NPM配置好的一个个host，被保存在了debian映射出来的那个目录？
原来都保存在了 docker-compose.yml 的目录下，
/www/server/panel/data/compose/NginxPorxyManager/template/data/nginx/proxy_host#

  1. 修改配置nginx问题 root@Debian11:/www/server/panel/data/compose/NginxPorxyManager/template/data/nginx/proxy_host# vi 1.conf

  2. 重启NPM docker-compose
    root@Debian11:/www/server/panel/data/compose/NginxPorxyManager/template# docker-compose restart

  3. 验证 https://artalk.carlzeng.com:4443/robots.txt
    User-agent: *
    Allow:/
    Works perfect

灵感来源：
如果需要 Nginx 反向代理， 这里提供一份 Nginx 配置参考
https://zh.wikipedia.org/zh-tw/Robots.txt

Debian 11的一些基础

Debian 11默认是关闭ssh的，如何开启？设置了自动开启，断电重启就无忧
    旧方案是：在BT面板中开启SSH开关，然后用carl用户登录进ssh，在su，就可以到root用户下
    新的：
        算了，为了debian11安全，就不开放ssh了；走面板，或者pve终端的ssh


artalk docker 没有自动重启，如何设置特定的docker自动重启？假设机器死机需要断电重启
    手动重启成功

缩短URL之简化4443端口成3端口

尝试在NPM的docker把443映射成4443，同时增加了映射到3（后来发现这个步骤是可选的）

原来仅需要在OP上，把3端口映射给重复的内部端口4443即可。
https://c.carlzeng.com:4443/tv
https://c.carlzeng.com:3/tv

Docker端口映射之一对多的几种情况

  1. 端口多对一，可行：访问宿主的多个端口可以映射到容器中的同一个端口。
    1
    # docker run -d -p 9000-9001:9000 tomcat:8.5-jre8
  2. 多对多的几种情况 9000-9001:9000-9001 可行
    1
    # docker run -d -p 9000-9001:9000-9001 tomcat:8.5-jre8

NPM弊端？

不知为何本地局域网可访问的http://192.168.6.116:881/ 无法映射代理到外网，来实现npm自己代理自己的目标。

真是奇怪，https://npm.carlzeng.com:4443/ 更可能是NPM自己做了什么设置？无法自己代理自己的web管理服务？

2023年12月初：解决办法：用在线云浏览器Firefox，远程过去访问本地局域网的NPM面板即可

Mamoto面板反代以后无法正常登录，也请使用在线云浏览器Firefox

J4125 pve半死状态

这种状态大约半个月左右出现一次；难受；这次是（已启动13天1小时20分57秒）

现象：

  1. 各个设备终端上网正常

  2. 画面卡死，无法登录 http://192.168.6.116:881/nginx/proxy

  3. SSH可以到达192.168.6.1

    1. web到OP也正常

  4. 无法连接pve https://192.168.6.2:8006

    1. This site can’t be reached192.168.6.2 took too long to respond.

  5. SSH无法到达bebian .116的

    1. kex_exchange_identification: read: Operation timed out
      banner exchange: Connection to 192.168.6.116 port 22: Operation timed out

  6. metaUI无法正常打开，http://192.168.6.116:9090/#/overview

    1. This site can’t be reached192.168.6.116 took too long to respond.

  7. StatCount 无法正常打开，http://192.168.6.116:8597/index.php?module=CoreHome&action=index&idSite=1&period=day&date=yesterday#?period=day&date=2023-12-01&idSite=1&category=Dashboard_Dashboard&subcategory=1

    1. This site can’t be reached192.168.6.116 took too long to respond.

  8. IPNAS 无法打开http://192.168.6.203:5000/

    1. 奇怪的是：用手机可以正常打开；反复测试中

  9. NAS中的docker Aria2 可以正常使用 https://aria2.carlzeng.com:4443/#!/downloading

  10. Debian clash 的 7890无法正常使用

  11. Debian

    1. artalk 正常
    2. bt 无法连接web
    3. dujiaoka正常https://buy.carlzeng.com:4443/
    4. Yourls正常https://c.carlzeng.com:3/admin/index.php
      1. Yourls后台可以正常登录查看https://c.carlzeng.com:3/admin/index.php
    5. metaUI又能正常打开了，http://192.168.6.116:9090/#/overview
      1. 可是，仍然无法连接到http://192.168.6.116:9091
    6. NPM无法正常打开http://192.168.6.116:881/nginx/proxy
    7. Hnet Web首页正常了https://proxy.carlzeng.com:4443/
    8. 电脑端的statcounter无法打开，可是手机端（在系统中）可以正常查看各种信息
      1. 奇怪

  12. 20231204昨天没有重启，后来自动就恢复了；今天又假死了

    1
    2
    nc -vz 192.168.6.116 881                                                                              
    nc: connectx to 192.168.6.116 port 881 (tcp) failed: No route to host

PVE, 以及PVE中的docker debian，NAS都下线了

可是OP还活着，一直充当主路由的工作

稀奇的是手机确可以ping通192.168.6.116；这简直无法理解

手机端也是无法打开NPM的881端口，可是matomo可以正常使用

重启一下MAC电脑，重新测试

重启MAC，链接NPM又正常了！pve又可以链接了; 原来问题的根源不是在J4125；汗，而是在用来发现问题的MAC上，引以为戒。下次核查的时候要多设备核实（才能去硬重启J4125）

无意间点进PVE，不看不知道，一看吓一跳：

原来很可能是pve的磁盘占用 96.69% (104.62 GiB的108.20 GiB）

我不知道/dev/sdb3(在SSD128上面, Reeinno CY128GB S1S3上面)为何就满了？里面放了什么了？
pve存储空间扩容 磁盘大小调整 proxmox6

采取措施（对debian和NAS）

​ docker volume prune
​ docker image prune

没招，找了一圈又一圈：没有找到解决办法。

尝试着把Win2008的备份10G的文件删除，PVE的使用率从96.69%降到87.55%。先用吧，观察着debian中docker的安装有没有占用这块128G的SSD盘？

Linux 查看当前开放端口

在K2P的padavan或者openwrt里面都是适用

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

#tcpdump 不会用啊

#想要查看那些客户端连接了？
#通过padavan的UI查询：网络信息 > 流量监控https://k2pzl.carlzeng.com:4443/Main_BWMon.asp

找到了服务器上frps的192.168.6.116:6006, frpc映射至192.168.123.189:5555
这样scrcpy -e
就会显示两个客户端了！
scrcpy -e
scrcpy 2.1.1 <https://github.com/Genymobile/scrcpy>
ERROR: Multiple (2) ADB devices over TCP/IP:
ERROR:     --> (tcpip)  192.168.6.116:6006              device  p230
ERROR:     --> (tcpip)  192.168.6.216:5555              device  p230
ERROR: Select a device via -s (--serial), -d (--select-usb) or -e (--select-tcpip)
ERROR: Server connection failed

#手动指定连接到那一个adb 5555 客户端（即便是被frp映射过的也一样）
scrcpy --tcpip=192.168.6.116:6006

重启docker服务

这是一个类似于把整台软路由重启一样的指令

磁盘占用率97%导致数据库无法写入，应用开始出错。 为什么重启？据说能减轻磁盘占用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
root@Debian11:/www/server/panel/data/compose/matomo# du -hs /var/lib/docker/                               
11G     /var/lib/docker/ 


> docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          17        14        5.674GB   624.4MB (11%)
Containers      14        14        224.4MB   0B (0%)
Local Volumes   0         0         0B        0B
Build Cache     0         0         0B        0B

> docker system prune -a
y

> docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          14        14        5.057GB   7.335MB (0%)
Containers      14        14        224.4MB   0B (0%)
Local Volumes   0         0         0B        0B
Build Cache     0         0         0B        0B
1
sudo systemctl restart  docker

重启 以后 引导磁盘大小92.47% (45.23 GiB的48.91 GiB)

重启以后，其他的服务都正常重启了，除了：Matomo，ChatgptNextWeb，和Firefox。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
1. docker start chatgpt-next-web

2. 添加
restart: always
到firefox的docker-compose.yml文件中
启动巨慢，表面上docker已经启动完成的状态，可实际中，观察日志
[cont-init   ] 15-cjk-font.sh: installing CJK font...
[cont-init   ] 15-cjk-font.sh: fetch https://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz
[cont-init   ] 15-cjk-font.sh: fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
[cont-init   ] 15-cjk-font.sh: fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
[cont-init   ] 15-cjk-font.sh: (1/1) Installing font-wqy-zenhei (0.9.45-r3)
要耗时4-5分钟左右

3. Matomo已经有restart: on-failure:3比较尴尬。

PVE 如何给docker debian虚拟机分配更多的磁盘空间？

目前是50G 92%的占用率。

防止 Docker 日志塞满硬盘（泪的教训）

/etc/docker/daemon.json

1
2
3
4
5
6
7
# 增加：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "20m",
"max-file": "3"
}
1
systemctl restart docker

无法解决问题，反而让docker无法启动数据库了（因为磁盘已满）

rm -rf /var/log/*

终于找到原因了BT 默认备份功能（默认每天备份panel文件夹下的所有内容）害死我了

采取行动：关闭宝塔面板自动备份功能

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
> cd /
> du -sh *
。。。
12G     var
35G     www
root@Debian11:/www# du -s /www/* | sort -nr                                                        
31497608        /www/backup                                                                        
4538716 /www/server                                                                                
652     /www/dk_project                                                                            
36      /www/wwwlogs                                                                               
8       /www/wwwroot                                                                               
4       /www/disk.pl                                                                               
root@Debian11:/www# bt                                                                             
===============宝塔面板命令行==================                                                    
(1) 重启面板服务           (8) 改面板端口                                                          
(2) 停止面板服务           (9) 清除面板缓存                                                        
(3) 启动面板服务           (10) 清除登录限制                                                       
(4) 重载面板服务           (11) 设置是否开启IP + User-Agent验证                                    
(5) 修改面板密码           (12) 取消域名绑定限制                                                   
(6) 修改面板用户名         (13) 取消IP访问限制                                                     
(7) 强制修改MySQL密码      (14) 查看面板默认信息                                                   
(22) 显示面板错误日志      (15) 清理系统垃圾                                                       
(23) 关闭BasicAuth认证     (16) 修复面板(检查错误并更新面板文件到最新版)                           
(24) 关闭动态口令认证          (17) 设置日志切割是否压缩                                           
(25) 设置是否保存文件历史副本  (18) 设置是否自动备份面板                                           
(26) 关闭面板ssl           (28) 修改面板安全入口                                                   
(0) 取消                   (29) 取消访问设备验证                                                   
===============================================                                                    
请输入命令编号：18                                                                                 
===============================================                                                    
正在执行(18)...                                                                                    
===============================================                                                    
|-检测到已开启面板自动备份功能,正在关闭...                                                         
|-已关闭面板自动备份功能                                                                           
root@Debian11:/www#

排查过程

  1. cd /. 然后 du -sh *
    1. 这样查找出来www目录占用了35G（不知情）
  2. du -s /www/* | sort -nr
    1. 按文件占用大小排序，找出最大的占用空间文件夹： /www/backup
  3. 清除所有的文件：/www/backup
  4. 运行bt 选18 关闭面板自动备份功能

这个BT还是更适合方便+初级用户+快速上线，很高心释放出了30G空间。下一步：找BT替换方案。

感谢列表：

一个反向代理神器——Nginx Proxy Manager>修改Docker配置

一种给PVE虚拟机磁盘扩容的方法