问题遇到的现象和发生背景
本人最近尝试用docker + nextcloud 搭建内网的云盘服务器，该服务器用VMware开虚机在个人电脑上搭建Linux系统，centos7.x。在搭建完成后，使用http://192.168.17.XX:自定义端口号，可以访问内部信息。
后来基于安全问题考虑，尝试下载teddysun/caddy 使用代理的方式，希望可以转成https://192.168.17.XX:自定义端口号的方式来访问。
因为在内网布局，估计也就一个办公室的几个小伙伴一起用，所以没有ssl证书，也没有申请域名。个人电脑物理机网卡ip 地址是 172.31.x.x/24.
问题相关代码，请勿粘贴截图
1.在centos7.x系统内用root账号，创建了如下文件夹：
mkdir -p /data/dockerdata/caddy/cert
mkdir -p /data/dockerdata/caddy/log
mkdir -p /data/dockerdata/caddy/picture
2. 自定义一个Caddyfile，实现2个端口的映射：
nextcloud 80->4430->54430
test 8080->3000->3000，希望能打开虚机内指定路径文件夹的个人图片kyo.jpg显示在浏览器内
cd /data/dockerdata/caddy/
vi Caddyfile
Caddyfile内容编辑如下：
for nextcloud
https://192.168.17.xx:4430 {
gzip
#自动签名
tls self_signed
timeouts 10s
log /var/log/caddy/nextcloud.log
Service discovery via well-known
redir /.well-known/carddav /remote.php/carddav 301
redir /.well-known/caldav /remote.php/caldav 301
proxy / 182.xx.0.x:80 { #内部docker自定义子网对应nextcloud容器
websocket
transparent
Nextcloud best practices and security
header_downstream Referrer-Policy "strict-origin-when-cross-origin"
header_downstream X-XSS-Protection "1; mode=block"
header_downstream X-Content-Type-Options "nosniff"
header_downstream X-Frame-Options "SAMEORIGIN"
}
header / Strict-Transport-Security "max-age=31536000;"
}
for test
https://192.168.17.xx:3000 {
gzip
#自动签名，很重要
tls self_signed
timeouts 10s
log /var/log/caddy/error.log
proxy / 192.168.17.xx:8080 {
#省略关联kyo.jpg图片的代码
websocket
transparent
}
}
3.创建和运行caddy的时候，再做了一次映射，代码如下：
docker run --name caddy --restart=always
--net network-zjh --ip 182.xx.0.x
-p 54430:4430
-p 3000:3000
-v /data/dockerdata/caddy/Caddyfile:/etc/caddy/Caddyfile
-v /data/dockerdata/caddy/cert:/etc/caddy/cert
-v /data/dockerdata/caddy/log:/var/log/caddy
-v /data/dockerdata/caddy/picture:/etc/caddy/picture
-d teddysun/caddy
运行结果及报错内容
2022-05-24T01:24:33.883156186Z Serving HTTPS on port 3000
2022-05-24T01:24:33.883160777Z https://192.168.17.xx:3000
2022-05-24T01:24:33.883169576Z Serving HTTP on port 4430
2022-05-24T01:24:33.883172498Z https://192.168.17.xx:4430
从上述来看，服务开启了没错，可是在本地物理机电脑浏览器输入https://192.168.17.xx:54430，https://192.168.17.xx:4430都打不开网页。
我的解答思路和尝试过的方法
后来，强行在虚机用firewall-cmd 相关命令打开54430 4430 3000等端口，从物理机telnet过去是通了，但是网页依旧打不开，最后，尝试修改nextcloud 目录下的config.php，追加一句：
'overwriteprotocol' => 'https',
问题依旧……
我想要达到的结果
静下心来，我仔细分析了逻辑，在使用代理前，浏览器用http://192.168.17.XX:自定义端口号，可以访问打开nextcloud的登录界面。但是用上caddy代理后，就不成功了，这代理Caddyfile内做了80-》4430的转换，在caddy创建的时候又执行了一次4430-》54430的转换。但很明显，服务都正常启用了，telnet端口也都通，
[root@test ~]# firewall-cmd --zone=public --list-ports
3000/tcp 54430 4430 ……都开放
最后在物理机的谷歌浏览器操作，分情况讨论
1.如尝试打开 https://192.168.17.xx:54430/ 或 http://192.168.17.XX:自定义端口号
此网站无法提供安全连接192.168.17.xx 发送的响应无效。
尝试运行 Windows 网络诊断。
ERR_SSL_PROTOCOL_ERROR
2.如尝试打开https://192.168.17.xx:4430/ ，错误提示如下
无法访问此网站192.168.17.xx 拒绝了我们的连接请求。
请试试以下办法：
检查网络连接
检查代理服务器和防火墙
ERR_CONNECTION_REFUSED
好长的文字，为能耐心读完的专家点赞，请教有什么好的追踪端口映射 路由的方法？Caddyfile有没有办法使用某个平台软件类似vc6平台那样设置断点逐条代码追踪的？
