最新升级需要重建启动器中的应用程序，但失败了。
看起来它在迁移 secondsite 数据库时失败了：
2025-08-21 06:44:42.493 UTC [867] discourse@discourse_nu ERROR: 必须是扩展 vector 的所有者
2025-08-21 06:44:42.493 UTC [867] discourse@discourse_nu STATEMENT: ALTER EXTENSION vector UPDATE TO ‘0.7.0’;
1 个迁移失败！
无法迁移 secondsite
查看关于此问题的讨论 Still an issue: ERROR: must be owner of extension vector - #2 by Falco
这解决了问题。
但是，我一年前报告的关于 nginx 和 secondsites 的问题仍然存在，
在容器内的 nginx 配置文件中，它会检查 URL 是否不是第一个站点，并将其更改为该站点。我再次注释掉了那段代码。
nginx 配置的处理方式发生了重大变化。
您是否设置了多站点但没有反向代理？
嗯，我将近两年没有怎么接触过 nginx 了，但这个问题在我两年前迁移到 Discourse 时就存在了，所以并不是新问题。
这是 nginx.conf 文件中的一段摘录：
server {
server_name huskerlist.tssi.com;
root /var/www/html;
allow 162.210.7.125;
allow 162.210.7.112;
allow 162.210.7.116;
allow 76.84.125.160;
allow 172.17.0.2;
allow 72.250.242.47;
allow all;
if ( $lockdown ) {
set $custom_server_name "lists.tssi.com";
return 300 "site is down for maintenance";
}
client_max_body_size 100M;
# Load configuration files for the default server block.
#include /etc/nginx/default.d/*.conf;
location / {
proxy_pass https://127.0.0.1:8443/;
#proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
error_page 404 /404.html;
location = /usr/share/nginx/html/40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /usr/share/nginx/html/50x.html {
}
listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/lists.tssi.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/lists.tssi.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
server_name nu-sports.tssi.com;
root /var/www/html;
allow 162.210.7.125;
allow 162.210.7.112;
allow 162.210.7.116;
allow 76.84.125.160;
allow 172.17.0.2;
allow 72.250.242.47;
allow all;
if ( $lockdown ) {
set $custom_server_name "lists.tssi.com";
rewrite ^ https://lists.tssi.com/n-maint.html;
}
client_max_body_size 100M;
# Load configuration files for the default server block.
#include /etc/nginx/default.d/*.conf;
location / {
proxy_pass https://127.0.0.1:8443/;
#proxy_pass http://unix:/var/discourse/shared/standalone/nginx2.http.sock:;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
error_page 404 /404.html;
location = /usr/share/nginx/html/40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /usr/share/nginx/html/50x.html {
}
listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/lists.tssi.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/lists.tssi.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
每次设置新容器（例如在重启期间）时，它都会重写
/etc/nginx/conf.d/outlets/server/20-https.conf 文件，而这些行会导致重定向到默认的 discourse 系统：
if ($https_host != huskerlist.tssi.com) {
rewrite (.$) https://huskerlist.tssi.com
}
有什么方法可以避免这种情况？这段代码有什么作用？
没错。你是在容器内部编辑那个文件吗？构建一个新容器会创建一个新容器。它不是在重写那个文件，而是重写所有文件。
你可以在 app.yml 中添加内容，以便在文件被重写后进行修改。
你对那个文件做了什么修改？为什么？
哦。等等。
你没有回答这个问题，但我认为答案是肯定的。
它强制了站点，因为你几乎从不希望你的站点可以通过多个主机名访问。
所以你需要向你的 app.yml 添加一些代码来撤销这一点。
很久以前，我在 Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy 中有一个解决方案。
所以你需要在一个 exec 中添加一个 sed，或者使用一些 replace 语句来删除或修改那部分。你可能仍然需要遵循那个主题中的内容（我认为它仍然有效）来获得多个 你现在可以使用 DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org 来为额外的hostname获取证书。
我想最聪明的解决方案可能是设法将其他主机名别名添加到那个 if ($http_host != 代码中。我现在没有任何这样设置的站点，所以我不太可能花时间去弄清楚它是否好玩。
但是，是的，web ssl template 有这个：
if (\\$http_host != ${DISCOURSE_HOSTNAME}) {
rewrite (.*) https://${DISCOURSE_HOSTNAME}\\$1 permanent;
}
所以你可以删除它，或者找到一种方法让它也检查你的其他主机名。
所以，基本上你的意思是，在同一台服务器上托管两个独立论坛的“secondsite”方法已损坏，并且不在要修复的列表中。
所以你可以删除它，或者找到一种方法让它也检查你的其他主机名。
在容器中删除它是我一直在做的事情，但每次容器启动或生成新的容器映像时，它都会将该代码放回去，因此需要在源头某处进行更改，以便在构建新容器时，它能在 app.yml 中正确地检查多个域。（这可能比仅仅删除那 3 行代码要好。）
如果构建 Web SSL 模板的代码不会更新以检查 app.yml 中的 secondsite（以及 thirdsite 等），那么这似乎需要在 app.yml 中完成，这对我来说是一个自定义修复，而不是为所有在单服务器上使用明显损坏的 secondsite 方法运行多个论坛的用户提供的修复。
现在我正在为客户进行一个大型系统迁移项目，而且这些网站在足球赛季期间最活跃，所以我需要设置我的测试环境来测试编写 app.yml 修正，而不是在现场尝试修复实时系统。
简单考虑一下，修复ssl模板有点棘手。
目前的逻辑是：如果站点不是A，就把它变成A。
引入第二个站点会使事情复杂化，因为如果它不是A也不是B，那么将其更改为A或B是否正确也不清楚。（这也许就是Discourse一直没有解决这个问题的原因。）
也许删除那些代码行是正确的做法，因为当有多个站点时，外部ngingx服务器应该只发送匹配A或B的https数据包。强制HTTP到HTTPS应该已经在外部nginx服务器中完成了。
它从未在支持列表上。推荐的方法一直是使用反向代理。我构思了一种不使用反向代理的方法。我的 hack 在几年前就坏了。
在没有反向代理的情况下进行多站点设置一直是一个障眼法。如果你是专业人士，你应该删除 ssl 和 Let’s Encrypt 模板，并使用处理 ssl 的反向代理。Cdck 使用 haproxy。我一直在使用 traefik。Caddy 很容易管理。我不再使用它，因为如果有人删除了他们站点的 cname，它会导致所有证书续订失败（现在可能不再是这种情况了，已经很多年了）。
既然我使用 nginx 和 proxy_pass 将流量传递到容器，我是否正确地认为我正在为多站点使用反向代理方法？
是的。我忘了那个了！
请将其设置为 HTTPS，并从您的 yml 文件中删除 SSL 和 Let’s Encrypt 模板。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.