Since a while, we see X-Accel-Mapping header missing messages emitted by the container in a quite high frequency, but not triggered by every visitor or ever navigation step. I see that this header is explicitly defined in the Nginx config, though not for all requests: discourse/config/nginx.sample.conf at main · discourse/discourse · GitHub
Since I cannot see this reported anywhere else in this forum, I wonder whether it could be related to the subdir setup we use, though I do not see how.
Not sure what exactly is emitting it, but I guess this should happen only if X-Sendfile-Type is set to X-Accel-Redirect, but X-Accel-Mapping is not set. And the config only defines both, or sets both empty 
.
Actually it is set only when accessing backups, and, more relevant, when accessing uploads. Just tested and verified, that whenever I view a post with an uploaded image or similar, it triggers that message. Looking at the config, it should not be possible that X-Accel-Redirect is set but X-Accel-Mapping not. Also this is a request header set by Nginx within the container, consumed by Discourse/unicorn/pitchfork/backend only, i.e. it does not enter or leave the container at all.
Ah, we configure Nginx to log to STDERR, and since I do not see this in Discourse logs, I am sure Nginx itself emits it. This is probably the reason it has not been recognized by anyone else, as it is in the Nginx log file. Does someone find time to check whether their shared/*/log/var-log/nginx/error.log contains these as well? If so, I’d check back with others who do not use a subdir setup, to narrow it down.