Nossas imagens de discurso não são exibidas em lightbox

Could someone help me to get the image lightboxing working.

I uploaded a image. image resolution is 1772 x 2362.

But Images are without thumbnails and without lightboxes.

I checked create thumbnails option.

Settings part: File > create thumbnails


My Discourse is on private network. But we opened the firewall to connect from the outside.
Version is v2.0.0.beta5+12.

image

What is the problem?

Possibly related:

Thank you for your reply.

I updated today to latest revision and already up to date.

and I tried safe mode.

but lightbox is not appearing no matter how I get the picture/image into the Post.

What shoud I do??

No problem. I wish I could help you more, but unfortunately, I do not have enough knowledge on the subject. Hopefully someone that knows more will respond soon. I would also watch the topic that I linked to. It might eventually have a solution posted.

In the mean time, you might want to take a look at your logs and see if there are similarities to the logs posted in that topic. I’m pretty sure the logs you would be interested in can be found by adding /logs to your forum’s base URL. So it would look something like https://example.com/logs The user in that topic also mentions a proxy. Are you using a proxy?

If you can provide this type of information, it should be helpful to someone that reads this topic and has a better understanding on the subject.

I wish you luck in solving the problem!

thank you tshenry.

our discourse is not using proxy and https.

I still do not know the cause of the problem. :cold_sweat:

Thank you. ^^

First thing first. If possible, upload that image to meta here. See if it works.

If it doesn’t work in meta, then it is much easier for the team to fix as there is their repo right here.

If it works in meta but not on your site, then there must be a setting conflict somewhere.

I can see that the image in your original post successfully lightboxes.

We’d prefer if you could upload to try first (try.discourse.org), that way we don’t start getting image uploads all over the place. If the image fails to lightbox on try, then feel free to upload it here so the example doesn’t get deleted when try is reset each day. If the image lightboxes on try then the issue is specific to your configuration as @schungx stated.

Estou executando a versão 2.5.0.beta6 e estou enfrentando o mesmo problema.
“Criar miniaturas” está ativo, mas não cria um lightbox, independentemente do tamanho da imagem.

Tenho uma segunda instância do Discourse com alguns meses de idade e, nela, há postagens antigas onde o lightbox funciona, mas não nas postagens novas.
Talvez seja um problema com uma atualização?

Se eu fizer o upload da mesma imagem para try.discourse.org, ela funciona corretamente com o lightbox lá.

Olá e bem-vindo ao Meta @Michael_Uray :wave:

Isso sugere que há um problema em algum lugar da sua configuração. Você poderia verificar o console do seu navegador em busca de erros ou enviar um link para o site que está apresentando problemas?

Acabei de criar um tópico de teste em uma nova instância do Discourse que configurei na semana passada.
A imagem tem 1920x1050, mas não abre em um lightbox.
https://dis.ctb.co.at/t/test-image-lightbox/44

Obrigado pelo link, Michael :+1:

Não estou vendo nenhum erro de JavaScript nessa página. Você pode verificar se há algum problema no Sidekiq?

your.site.com/sidekiq

Especificamente, essas abas

Além disso, você pode confirmar que seguiu o guia oficial ao configurar seu site?

Até onde posso ver, não há problemas.
2020-06-07_16-07-18_Sidekiq_-_Mozilla_Firefox

Na verdade, segui este guia, mas alterei o caminho e adaptei essas mudanças no arquivo app.yml.

volumes:
  - volume:
      host: /var/docker/dis.ctb.co.at/shared/standalone
      guest: /shared
  - volume:
      host: /var/docker/dis.ctb.co.at/shared/standalone/log/var-log
      guest: /var/log

Na segunda instalação, onde o lightbox funcionava antes, o caminho era inicialmente “/var/docker” e eu o alterei posteriormente para outro local.
Pode ser que o problema do lightbox tenha começado com essa mudança de caminho. — Não tenho certeza.

Será que perdi alguma configuração para o novo caminho?
As linhas acima foram as únicas que encontrei que apontavam para o diretório original “/var/docker”.

Acabei de tentar movê-lo de volta para “/var/discourse” para confirmar que foi a alteração do caminho que causou o problema, mas o mesmo erro ocorre lá com o caminho original.

Ele também roda atrás de um proxy reverso nginx que faz a criptografia SSL, se isso for relevante, mas não alterei nada na configuração dele desde que deixou de funcionar na outra instalação.

Fiz essas configurações para o nginx no arquivo .yml correspondente.

- replace:
      filename: /etc/nginx/conf.d/discourse.conf
      from: "types {"
      to: |
        set_real_ip_from 172.18.0.0/16;
        real_ip_header X-Forwarded-For;
        real_ip_recursive on;
        types {

Se não for o caminho, o que mais poderia causar esse problema de lightbox?

Movi de volta para “/var/docker/dis.ctb.co.at”.
Esta é minha configuração atual em yml (apenas alterei os dados pessoais). Poderia haver algo errado aqui, ou isso é um problema do Discourse?

## este é o modelo de contêiner Docker Discourse tudo-em-um, autônomo
##
## Após fazer alterações neste arquivo, você DEVE reconstruir
## /var/discourse/launcher rebuild app
##
## TENHA *MUITO* CUIDADO AO EDITAR!
## ARQUIVOS YAML SÃO SUPER SUPER SENSÍVEIS A ERROS DE ESPAÇAMENTO OU ALINHAMENTO!
## visite http://www.yamllint.com/ para validar este arquivo conforme necessário

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
## Descomente estas duas linhas se desejar adicionar o Lets Encrypt (https)
#  - "templates/web.ssl.template.yml"
#  - "templates/web.letsencrypt.ssl.template.yml"

## quais portas TCP/IP este contêiner deve expor?
## Se você quiser que o Discourse compartilhe uma porta com outro servidor web como Apache ou nginx,
## consulte https://meta.discourse.org/t/17247 para detalhes
expose:
        #  - "80:80"   # http
        #  - "443:443" # https
  - "127.0.0.1:3041:80"

docker_args:
  - "--network=nginx-br"

params:
  db_default_text_search_config: "pg_catalog.english"

  ## Defina db_shared_buffers para no máximo 25% da memória total.
  ## será definido automaticamente pelo bootstrap com base na RAM detectada, ou você pode sobrescrever
  db_shared_buffers: "4096MB"

  ## pode melhorar o desempenho de classificação, mas aumenta o uso de memória por conexão
  #db_work_mem: "40MB"

  ## Qual revisão do Git este contêiner deve usar? (padrão: tests-passed)
  #version: tests-passed

env:
  LANG: en_US.UTF-8
  # DISCOURSE_DEFAULT_LOCALE: en

  ## Quantas solicitações web simultâneas são suportadas? Depende da memória e dos núcleos da CPU.
  ## será definido automaticamente pelo bootstrap com base nas CPUs detectadas, ou você pode sobrescrever
  UNICORN_WORKERS: 8

  ## TODO: O nome de domínio ao qual esta instância do Discourse responderá
  ## Obrigatório. O Discourse não funcionará com um número IP puro.
  DISCOURSE_HOSTNAME: dis.ctb.co.at

  ## Descomente se quiser que o contêiner seja iniciado com o mesmo
  ## nome de hostname (opção -h) especificado acima (padrão "$hostname-$config")
  #DOCKER_USE_HOSTNAME: true

  ## TODO: Lista de e-mails separados por vírgula que serão feitos administradores e desenvolvedores
  ## no primeiro exemplo de inscrição 'user1@example.com,user2@example.com'
  DISCOURSE_DEVELOPER_EMAILS: 'nothing@nothing.com'

  ## TODO: O servidor de e-mail SMTP usado para validar novas contas e enviar notificações
  ## Endereço SMTP, nome de usuário e senha são obrigatórios
  ## AVISO: o caractere '#' na senha do SMTP pode causar problemas!
  DISCOURSE_SMTP_ADDRESS: mailserver.nothing.com
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: nothing@nothing.com
  DISCOURSE_SMTP_PASSWORD: "secret"
  DISCOURSE_SMTP_ENABLE_START_TLS: false           # (opcional, padrão true)
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none

  ## Se você adicionou o modelo Lets Encrypt, descomente abaixo para obter um certificado SSL gratuito
  #  LETSENCRYPT_ACCOUNT_EMAIL: me@example.com

  ## O endereço CDN http ou https para esta instância do Discourse (configurado para buscar)
  ## consulte https://meta.discourse.org/t/14857 para detalhes
  #DISCOURSE_CDN_URL: https://discourse-cdn.example.com

  VIRTUAL_HOST: dis.ctb.co.at
  VIRTUAL_PORT: 9002
  LETSENCRYPT_HOST: dis.ctb.co.at
  LETSENCRYPT_EMAIL: nothing@nothing.com

 

## O contêiner Docker é sem estado; todos os dados são armazenados em /shared
volumes:
  - volume:
      host: /var/docker/dis.ctb.co.at/shared/standalone
      guest: /shared
  - volume:
      host: /var/docker/dis.ctb.co.at/shared/standalone/log/var-log
      guest: /var/log

## Plugins vão aqui
## consulte https://meta.discourse.org/t/19157 para detalhes
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git

## Quaisquer comandos personalizados para executar após a construção
run:
  - exec: echo "Início dos comandos personalizados"
  ## Se você quiser definir o endereço de e-mail 'De' para seu primeiro registro, descomente e altere:
  ## Após receber o primeiro e-mail de inscrição, recomente a linha. Só precisa ser executado uma vez.
  #- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
  - exec: echo "Fim dos comandos personalizados"

  - replace:
      filename: /etc/nginx/conf.d/discourse.conf
      from: "types {"
      to: |
        set_real_ip_from 172.18.0.0/16;
        real_ip_header X-Forwarded-For;
        real_ip_recursive on;
        types {

Agora descobri que isso só acontece quando a opção Forçar seu site a usar apenas HTTPS está ativa no momento em que o post com a imagem é criado.
Eu tinha isso ativo na outra instalação desde o início, mas de repente parou de funcionar, talvez causado por uma atualização do nginx ou do Discourse.

O nginx não mostra nada estranho até onde posso ver.

nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:09:52 +0200] "POST /message-bus/d333cb718e2d49b9947ec22c0762e47d/poll HTTP/2.0" 200 2 "https://dis.ctb.co.at/t/test-image-lightbox/44/7" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:09:58 +0200] "POST /presence/publish HTTP/2.0" 200 36 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:09:58 +0200] "POST /message-bus/d333cb718e2d49b9947ec22c0762e47d/poll HTTP/2.0" 200 253 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:09:58 +0200] "POST /uploads.json?client_id=d333cb718e2d49b9947ec22c0762e47d HTTP/2.0" 200 431 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:00 +0200] "POST /draft.json HTTP/2.0" 200 56 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:08 +0200] "POST /message-bus/d333cb718e2d49b9947ec22c0762e47d/poll HTTP/2.0" 200 253 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:08 +0200] "POST /presence/publish HTTP/2.0" 200 36 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:16 +0200] "POST /draft.json HTTP/2.0" 200 56 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:18 +0200] "POST /draft.json HTTP/2.0" 200 56 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:19 +0200] "POST /message-bus/d333cb718e2d49b9947ec22c0762e47d/poll HTTP/2.0" 200 251 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:19 +0200] "POST /presence/publish HTTP/2.0" 200 36 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:19 +0200] "POST /message-bus/d333cb718e2d49b9947ec22c0762e47d/poll HTTP/2.0" 200 194 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:19 +0200] "POST /posts HTTP/2.0" 200 733 "https://dis.ctb.co.at/t/test-image-lightbox/44/6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:21 +0200] "POST /message-bus/2027eab545f744e3a8dff7e81e4748d4/poll?dlp=t HTTP/2.0" 200 258 "https://dis.ctb.co.at/admin/site_settings/category/security?filter=" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:22 +0200] "POST /message-bus/d333cb718e2d49b9947ec22c0762e47d/poll HTTP/2.0" 200 336 "https://dis.ctb.co.at/t/test-image-lightbox/44/7" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:22 +0200] "GET /posts/82 HTTP/2.0" 200 749 "https://dis.ctb.co.at/t/test-image-lightbox/44/7" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:22 +0200] "GET /about/live_post_counts.json HTTP/2.0" 200 52 "https://dis.ctb.co.at/t/test-image-lightbox/44/7" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:24 +0200] "POST /message-bus/2027eab545f744e3a8dff7e81e4748d4/poll?dlp=t HTTP/2.0" 200 33 "https://dis.ctb.co.at/admin/site_settings/category/security?filter=" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:27 +0200] "POST /topics/timings HTTP/2.0" 200 0 "https://dis.ctb.co.at/t/test-image-lightbox/44/7" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nnginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:47 +0200] "POST /message-bus/d333cb718e2d49b9947ec22c0762e47d/poll HTTP/2.0" 200 2 "https://dis.ctb.co.at/t/test-image-lightbox/44/7" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"
nginx          | nginx.1    | dis.ctb.co.at 84.115.50.36 - - [14/Jun/2020:16:10:47 +0200] "POST /message-bus/d333cb718e2d49b9947ec22c0762e47d/poll HTTP/2.0" 200 104 "https://dis.ctb.co.at/t/test-image-lightbox/44/7" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"

A propósito, nnginx não é um erro de digitação neste log; por algum motivo, ele apareceu realmente assim.

Alguma ideia de por que Forçar seu site a usar apenas HTTPS poderia causar problemas no lightbox?

Geralmente, isso se deve a uma configuração incorreta de esquemas complexos de proxy reverso, na minha experiência. Subpastas adicionam complexidade adicional (e, portanto, variáveis) também.

Hmm, o que poderia estar errado com minha configuração do proxy nginx?

version: '3'

services:

  nginx:
    image: jwilder/nginx-proxy:alpine
    labels:
      - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true"
    container_name: nginx
    networks:
      - nginx_nw
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./data/conf.d:/etc/nginx/conf.d:rw
      - ./data/vhost.d:/etc/nginx/vhost.d:rw
      - ./data/html:/usr/share/nginx/html:rw
      - ./data/certs:/etc/nginx/certs:ro
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro
    restart: unless-stopped

  letsencrypt:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: letsencrypt
    depends_on:
      - nginx
    networks:
      - nginx_nw
    volumes:
      - ./data/certs:/etc/nginx/certs:rw
      - ./data/vhost.d:/etc/nginx/vhost.d:rw
      - ./data/html:/usr/share/nginx/html:rw
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    restart: unless-stopped

networks:
    nginx_nw:
        external:
            name: nginx-br

Estou executando duas instalações separadas do Discourse através desse proxy nginx, além de uma instância do Nextcloud. Na primeira instalação do Discourse, o lightbox funcionava antes e, de repente, parou de funcionar. Na verdade, não alterei nada na configuração do proxy desde que estava funcionando.

Curiosamente, ele ainda cria alguns arquivos e pastas em /var/discourse, mesmo tendo definido os volumes para outro diretório.

volumes:
  - volume:
      host: /var/docker/dis.ctb.co.at/shared/standalone
      guest: /shared
  - volume:
      host: /var/docker/dis.ctb.co.at/shared/standalone/log/var-log
      guest: /var/log

Então, imagino que haja algum problema com o local da pasta em algum lugar.

root@dk1:/var/discourse# tree -d
.
└── shared
    └── standalone
        ├── backups
        ├── log
        │   ├── rails
        │   └── var-log
        │       ├── nginx
        │       ├── postgres
        │       └── redis
        ├── postgres_backup
        ├── postgres_data
        │   ├── base
        │   │   ├── 1
        │   │   ├── 14049
        │   │   ├── 14050
        │   │   └── 16384
        │   ├── global
        │   ├── pg_commit_ts
        │   ├── pg_dynshmem
        │   ├── pg_logical
        │   │   ├── mappings
        │   │   └── snapshots
        │   ├── pg_multixact
        │   │   ├── members
        │   │   └── offsets
        │   ├── pg_notify
        │   ├── pg_replslot
        │   ├── pg_serial
        │   ├── pg_snapshots
        │   ├── pg_stat
        │   ├── pg_stat_tmp
        │   ├── pg_subtrans
        │   ├── pg_tblspc
        │   ├── pg_twophase
        │   ├── pg_wal
        │   │   └── archive_status
        │   └── pg_xact
        ├── postgres_run
        │   └── 12-main.pg_stat_tmp
        ├── redis_data
        ├── state
        │   ├── anacron-spool
        │   └── logrotate
        ├── tmp
        │   ├── backups
        │   └── restores
        └── uploads
            └── default
                ├── optimized
                │   └── 1X
                └── original
                    └── 1X

52 diretórios

Será que perdi alguma configuração para o novo local da pasta?

Nunca aconteceu que arquivos fossem criados em /var/discourse; talvez eu tenha visto alguns arquivos antigos.

Agora mudei de nginx para traefik para garantir que o problema não venha do nginx, mas o problema ainda persiste. Isso indica para mim que provavelmente há um problema no lado do Discourse e não no lado do proxy.

A mesma situação ocorre com o traefik: se “https forçado” estiver desativado quando a imagem for publicada, a lightbox funciona perfeitamente, mesmo que eu habilite “https forçado” depois.
O mais que eu poderia verificar?

Ele mostra um erro no arquivo de log, indicando que não é possível acessar /uploads/....

Não foi possível acessar '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' para obter suas dimensões.

Posso acessar a imagem sem problemas se digitar a URL em um navegador:
https://domain.com/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png

Completed 200 OK em 23ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 3000)
Completed 200 OK em 318ms (Views: 1.2ms | ActiveRecord: 0.0ms | Allocations: 50347)
Não foi possível acessar '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' para obter suas dimensões.
Started GET "/posts/96" para 84.115.50.36 em 2020-07-04 14:15:14 +0000
Processing by PostsController#show as JSON
  Parameters: {"id"=>"96"}

Não há erro quando o HTTPS não é forçado.

Completed 200 OK em 18ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 3050)
Completed 200 OK em 296ms (Views: 0.5ms | ActiveRecord: 0.0ms | Allocations: 49562)
Started GET "/posts/97" para 84.115.50.36 em 2020-07-04 14:17:43 +0000
Processing by PostsController#show as JSON
  Parameters: {"id"=>"97"}

Parece que o Discourse, por algum motivo, baixa novamente a imagem do servidor web para fazer algo relacionado ao lightbox.
Se eu baixar essa imagem manualmente dentro do contêiner Docker do Discourse, ele tenta acessar o servidor web diretamente pelo seu IP interno, em vez de acessá-lo através do proxy. Isso funciona via HTTP, mas não via HTTPS.

O próprio servidor web só tem HTTP disponível, mas ele tenta acessá-lo via HTTPS, o que falha.

Estou me perguntando por que o Discourse baixa a imagem novamente do servidor web em vez de acessá-la internamente, sem usar HTTP/HTTPS.

Edição: Descobri que renomeei o app.yml para domain.name.yml, o que fez com que o Docker alterasse o nome DNS de domain.name para seu IP interno. Renomeei para domain_name.yml e tudo está funcionando corretamente agora.

Se os dois pontos no YML estão causando isso, parece algo que deveria gerar um aviso no launcher?