您好，
从我的网络检查时，我看到端口是关闭的：
PS C:\Users\mwojt> nmap 192.168.131.211
Nmap scan report for 192.168.131.211
PORT STATE SERVICE
22/tcp open ssh
80/tcp closed http
443/tcp closed https
但是当从 Ubuntu 机器内部对 localhost 运行相同的命令时，它显示为打开：
root@ubuntu-discourse:~# nmap localhost
Nmap scan report for localhost (127.0.0.1)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
但是，如果我从同一个 Ubuntu 虚拟机运行检查 IP 地址到我看到这个：
root@ubuntu-discourse:~# nmap 192.168.131.211
Nmap scan report for ubuntu-discourse (192.168.131.211)
PORT STATE SERVICE
22/tcp open ssh
80/tcp filtered http
443/tcp filtered https
所以，端口显示为过滤状态。
root@ubuntu-discourse:~# ufw status
Status: active
To Action From
-- ------ ----
80 ALLOW Anywhere
443 ALLOW Anywhere
22 ALLOW Anywhere
80 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
22 (v6) ALLOW Anywhere (v6)
并且 Docker 端口转发似乎设置正确：
root@ubuntu-discourse:~# docker port 6922c7802903
80/tcp -> 0.0.0.0:80
80/tcp -> [::]:80
443/tcp -> 0.0.0.0:443
443/tcp -> [::]:443
我哪里做错了？问题出在哪里？
我又花了 90 分钟安装 Discourse。这次是在一台独立的物理机上安装，以排除虚拟环境的问题，并且我遇到了完全相同的问题，尽管我仔细遵循了 GitHub 上的说明。
难道这个根本就无法正常工作吗？？
Ed_S
2024 年4 月 19 日 17:14
3
Marek Wojtaszek:
从我的网络检查时
问题会不会出在您那边？我看到的结果与您非常相似，我的 Discourse 实例运行正常。
您能通过代理（例如 Browserling）访问您的实例吗？
编辑：等等，您的地址 192.168.131.211 是一个本地地址，不应该能从外部访问。
编辑：当您在 Discourse 主机上尝试运行 netstat -rn 时，您看到了什么？
Ed S:
netstat -rn
这是我的 netstat：
root@ubuntu-forum:/var/discourse# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.131.1 0.0.0.0 UG 0 0 0 enp1s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.130.0 0.0.0.0 255.255.254.0 U 0 0 0 enp1s0
192.168.131.1 0.0.0.0 255.255.255.255 UH 0 0 0 enp1s0
192.168.131.152 0.0.0.0 255.255.255.255 UH 0 0 0 enp1s0
除了在 Ubuntu 上安装的 Discourse，我还安装了 Talkyard（一个与 Discourse 类似的论坛引擎），同样在 Docker 中，并且运行得非常好。所以我想我也会尝试在 Debian 上安装 Discourse。
我的 Debian 上的 Netstat -rn 看起来是这样的：
root@debian-12:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.131.1 0.0.0.0 UG 0 0 0 ens18
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.26.0.0 0.0.0.0 255.255.255.128 U 0 0 0 br-886bebfa13ae
192.168.130.0 0.0.0.0 255.255.254.0 U 0 0 0 ens18
不确定这是否有帮助。
Ed_S
2024 年4 月 20 日 09:05
5
Marek Wojtaszek:
论坛网站无法打开，提示服务不可用
我认为 Discourse 只能通过域名访问，所以您是否设置了可以使用浏览器和域名访问您的网站？如果您完全在自己的局域网内，也许可以通过 hosts 文件来实现，但不确定。我认为服务器、客户端（可能还有 Docker）都需要能够进行名称查找。
我有一个本地 DNS 服务器，它将我的网络名称解析为主机，因此它的工作方式与从外部世界一样。
我刚刚在 DigitalOcean 虚拟机上成功安装了 Discourse。我将使用它作为我本地配置的参考。我立即注意到的一件事是虚拟机上的 hosts 文件——它有以下条目：
希望就是这个了。我会告诉你。
不，失败了……经过三天的挣扎，我彻底失败了，我累了……
请查看我录制的安装视频，并告诉我——我哪里做错了。
Ed_S
2024 年4 月 20 日 11:55
8
也许值得一试lsof -i
看起来 Discourse 运行正常，但网络状况使其无法访问。
好的，我找到了根本原因……我检查了 Docker 日志，发现 Nginx 服务器根本没有启动，因为它在获取 Let’s Encrypt 证书时失败（请参见附件日志）docker_logs_not_working.txt (10.0 KB)
现在我需要弄清楚如何解决这个问题。事实上，我甚至不需要 SSL，因为我使用的是带有自己 SSL 证书的反向代理。因此，它可以轻松地通过端口 80 与 Discourse 通信。不确定 Discourse 服务器是否会喜欢。
Jagster
2024 年4 月 20 日 12:41
10
如果您进行搜索，就会发现这是本地设置（即内部网）失败的最常见原因。Discourse 需要 SSL。
我的 DNS 由 Cloudflare 托管，因此我可以轻松获取我的 LetsEncrypt 证书，因为我可以提供 API 密钥。我可以在 Discourse 中配置 ACME 以使我的证书配置顺利工作吗？我在手册中找不到，但也许是我搜索得不好。
经过一番艰苦的斗争，我终于成功修复了它。
需要执行的操作如下：
docker ps
使用以下命令访问 Docker 容器的 shell：
docker exec -it [container_id or name] bash
将 Cloudflare API 密钥和电子邮件导出为环境变量。这是为了允许“acme.sh”脚本通过 Cloudflare API 进行身份验证，以创建和删除 DNS 挑战所需的 DNS 记录。我使用了您 Cloudflare 账户中的实际电子邮件地址和全局 API 密钥。
export CF_Key="your_cloudflare_global_api_key"
export CF_Email="your_cloudflare_email_address"
将目录更改为：
cd /shared/letsencrypt
使用 --issue 命令运行 acme.sh，指定您想使用 dns_cf（DNS Cloudflare）模式来处理 DNS 挑战。将 yourdomain.com 替换为您想要获取证书的域名。
./acme.sh --issue --dns dns_cf -d yourdomain.com -d *.yourdomain.com
成功创建证书后，脚本将显示其复制到的目录。在我的例子中是：
Your cert is in: /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.cer
Your cert key is in: /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.key
The intermediate CA cert is in: /root/.acme.sh/sprawy.info.pl_ecc/ca.cer
And the full chain certs is there: /root/.acme.sh/sprawy.info.pl_ecc/fullchain.cer
编辑 discourse.conf 文件以更新证书路径：
nano /etc/nginx/conf.d/discourse.conf
现有的 ssl_certificate 和 ssl_certificate_key 行应替换为：
ssl_certificate /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.cer;
ssl_certificate_key /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.key;
这样它现在就指向了新的证书位置。
运行此命令测试配置：
nginx -t
如果没有错误——重新加载 Web 服务器：
nginx -s reload
然后——瞧！
2 个赞
Ed_S
2024 年4 月 20 日 17:16
13
好消息，祝贺你们解决了这个问题。我想值得注意的是，使用 Let’s Encrypt，如果你连续多次请求证书失败，你会被锁定（我记得是 7 天）。所以，要小心确保这些请求都正确。
2 个赞
