[SOLVED] No browser auto-refresh of federated and local feeds


Since the 1.3.1 (not very sure about that) we have no more auto-refresh in browser for federated and local feeds.

I installed my instance using the tuto of Angristan (Installer une instance de Mastodon sous Debian 8 | Angristan), on last 8 or 9 april (may be lot of things have changed sinced then).

I installed it directly on a debian 8 server (not using docker) and here is my nginx conf file (I suppose that my problems come from here, but i’m not very familiar with nginx, so…):

map $http_upgrade $connection_upgrade {
 default upgrade;
 '' close;
server {
 listen 80;
 listen [::]:80;
 server_name cafe.des-blogueurs.org;
 return 301 https://cafe.des-blogueurs.org$request_uri;

 access_log /dev/null;
 error_log /dev/null;

server {
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 server_name cafe.des-blogueurs.org;

 if ($host = www.cafe.des-blogueurs.org) {
  return 301 https://cafe.des-blogueurs.org$request_uri;

 access_log /var/log/nginx/mstdn-access.log;
 error_log /var/log/nginx/mstdn-error.log;

 ssl_certificate /etc/letsencrypt/live/cafe.des-blogueurs.org/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/cafe.des-blogueurs.org/privkey.pem;
 ssl_protocols TLSv1.2;
 ssl_prefer_server_ciphers on;
 add_header Strict-Transport-Security "max-age=15552000; preload";

 keepalive_timeout 70;
 sendfile on;
 client_max_body_size 0;
 gzip on;
 gzip_disable "msie6";
 gzip_vary on;
 gzip_proxied any;
 gzip_comp_level 6;
 gzip_buffers 16 8k;
 gzip_http_version 1.1;
 gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

 root /home/mastodon/live/public;

 location / {
  try_files $uri @proxy;

 location ~ ^/(assets|system/media_attachments/files|system/accounts/avatars) {
  add_header Cache-Control "public, max-age=31536000, immutable";

 location @proxy {
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto https;
  proxy_set_header Proxy "";
  proxy_pass_header Server;
  proxy_buffering off;
  proxy_redirect off;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
  tcp_nodelay on;

 location /api/v1/streaming {
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto https;
  proxy_set_header Proxy "";
  proxy_buffering off;
  proxy_redirect off;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
  tcp_nodelay on;

 error_page 500 501 502 503 504 /500.html;

The different sidekiq queues seem to run normally.

Which log can I explore to detect a potential issue, and what should I specially look for? Any advice about this issue?

Thank’s a lot

Does this thread help you?

Not really as I have not (yet) the CSP header in the nginx conf file, so it cannot be the source of my issue

Maybe it is, cause you don’t have it? And are you running 1.3.3?

Yes I’m running the 1.3.3 release and I’m going to add the CSP policies in the nginx conf file… Will see

nginx conf file reviewed and the CSP header is now in da place (checked), but still no auto-refresh.

I also check the browser console but I only have a lot of react intl error (translation missing) and nothing more

Very weird, from my point of vue…

I found my errors checking the developer tools in Firefox and Chromium. Maybe that can help you. For me it was easy , cause it said it couldn’t connect to example.com. Another tip is to follow the troubleshoot advises from other people in that mentioned thread, like checking if 4000 port with nmap.

Thanks for advices, I saw your old issue and I have carefully check the CSP directive and I put the url of my instance :slight_smile:

I will have a check about the port 4000…

I did a nmap -A cafe.des-blogueurs.org -p 4000 and here is the output (seems to not be good, but why ?):

Starting Nmap 6.47 ( http://nmap.org ) at 2017-05-21 09:47 CEST
Nmap scan report for cafe.des-blogueurs.org (
Host is up (0.000070s latency).
4000/tcp open  remoteanything?
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.7 - 3.15
Network Distance: 0 hops

I see some “Error: Missing access token”, do you know where it may come from?

And also I see that cafe.des-blogueurs.org is resolved as rather than (as expected for proxy in nginx conf file). Should I take care about this?

I don’t think is the problem.

But the access token probably is. I am not 100% sure how that one is created, but in .env.production you have to put 3 different tokens, you generate with rake secret:

# Use this only if you need to run mastodon on a different domain than the one used for federation.
# Do not use this unless you know exactly what you are doing.
# WEB_DOMAIN=mastodon.example.com

# Application secrets
# Generate each with the `rake secret` task (`docker-compose run --rm web rake secret` if you use docker compose)

Maybe an idea to check those. If that’s ok, you have to ask someone else.

Good luck!

Ok for app secrets, but they have been generate since the very beginning of installation and have never been modified since.

Is there any method to “validate” them?

I really don’t know. :neutral_face:

App secrets shouldn’t change. vs might be the issue, but you should really check browser console to see what the actual error is.

I already check browser console and the only error I have are about missing translations which I think is not a problem and should not have these kind of side effects.

I will have a look about the localhost IP, may be it’s the point!

Thanks for advice

Well, my bad!

We, in order to develop our own look, had branch not at the 1.3.2 tag (as we have planned to), but some commits after and specially after the “Use PostgreSQL inheritance for blocks and mutes (#2520)” which have been revert later on the master branch, but not on 1.3 branch, and, my bad again, I forgot to make a db:migrate in order to apply schema modification implied by this commit.

So I revert this commit on our branch and after updating our instance, it seems to be fully operational \o/

1 Like

And about rather than it does not care as 127/8 address are used for loopback (localhost).

1 Like