Query Monitor - Nginx 502 error when a page is being saved

[UmeshSingla]

I'm unable to work on site with Query monitor installed, nginx throws a 502 error upon trying to update the page

System Details: Macbook Pro M1

Setup: WordPress Multisite No proxy

Upon trying to save the page I get 502 error, in the Nginx gateway logs I keep getting following errors:

nginx.1 | 2022/03/15 10:35:34 [error] 47#47: *14 upstream sent too big header while reading response header from upstream, client: 10.0.0.1, server: one.wordpress.test, request: "POST /sitename/wp-json/wp/v2/pages/116?_locale=user HTTP/1.1", upstream: "http://10.0.128.3:80/sitename/wp-json/wp/v2/pages/116?_locale=user", host: "one.wordpress.test", referrer: "http://one.wordpress.test/sitename/wp-admin/post.php?post=116&action=edit"

What's the possible workaround for this?

I've tried changing the xdebug settings to check if it was increasing the header size but it didn't help.

[kmgalanakis]

Same issue here but in my case I'm trying to render a block and the error is the following:

2023-09-25 11:51:58 nginx.1     | 2023/09/25 08:51:58 [error] 53#53: *1339 upstream sent too big header while reading response header from upstream, client: 10.0.0.1, server: getac.test, request: "GET /intl/wp-json/wp/v2/block-renderer/getac/content-listing?context=edit&attributes%5Btitle%5D=Related%20to%20%3Cstrong%3EOil%20and%20Gas%3C%2Fstrong%3E&attributes%5Blayout%5D=3-columns&attributes%5BcurationMode%5D=manual&attributes%5BcontentItems%5D%5B0%5D=46295&attributes%5BcontentItems%5D%5B1%5D=259782&attributes%5BcontentItems%5D%5B2%5D=97667&attributes%5BcontentLimit%5D=3&attributes%5BcontentTags%5D%5B0%5D=292&attributes%5BshowImage%5D=true&attributes%5BshowAuthor%5D=false&attributes%5BshowDate%5D=false&attributes%5BshowExcerpt%5D=true&post_id=353112&edit=1&currentBlockId=879f83d0-61bc-46ff-bd99-4621a4243afc&blocksIds=%5B%2217b89226-1d93-4980-ba8e-9e157b4be09f%22%2C%22879f83d0-61bc-46ff-bd99-4621a4243afc%22%2C%2294491d02-4544-4418-ae8e-fb162b96b601%22%2C%22194c2905-e243-4174-8f1a-3950b7e4baae%22%5D&_locale=user HTTP/2.0", upstream: "http://10.0.128.4:80/intl/wp-json/wp/v2/block-renderer/getac/content-listing?context=edit&attributes%5Btitle%5D=Related%20to%20%3Cstrong%3EOil%20and%20Gas%3C%2Fstrong%3E&attributes%5Blayout%5D=3-columns&attributes%5BcurationMode%5D=manual&attributes%5BcontentItems%5D%5B0%5D=46295&attributes%5BcontentItems%5D%5B1%5D=259782&attributes%5BcontentItems%5D%5B2%5D=97667&attributes%5BcontentLimit%5D=3&attributes%5BcontentTags%5D%5B0%5D=292&attributes%5BshowImage%5D=true&attributes%5BshowAuthor%5D=false&attributes%5BshowDate%5D=false&attributes%5BshowExcerpt%5D=true&post_id=353112&edit=1&currentBlockId=879f83d0-61bc-46ff-bd99-4621a4243afc&blocksIds=%5B%2217b89226-1d93-4980-ba8e-9e157b4be09f%22%2C%22879f83d0-61bc-46ff-bd99-4621a4243afc%22%2C%2294491d02-4544-4418-ae8e-fb162b96b601%22%2C%22194c2905-e243-4174-8f1a-3950b7e4baae%22%5D&_locale=user", host: "getac.test", referrer: "https://getac.test/wp-admin/post.php?post=353112&action=edit&lang=intl"

Note that I'm getting this error in the global gateway nginx log.

I know I need to increase the proxy buffers, I figured this out by googling this issue here https://www.cyberciti.biz/faq/nginx-upstream-sent-too-big-header-while-reading-response-header-from-upstream/

I just don't know where I have to make those changes.

@UmeshSingla did you make any progress?

[darylldoyle]

This is a known issue with QM adding stack traces to the response headers: https://github.com/johnbillion/query-monitor/issues/708

There are a number of filters available within QM that would allow you to remove these:

// Remove the redirects from AJAX headers.
remove_filter( 'qm/outputter/headers', 'register_qm_output_headers_redirects', 140 );

// Remove PHP errors from AJAX headers.
remove_filter( 'qm/outputter/headers', 'register_qm_output_headers_php_errors', 110 );

// Remove the overview section from the AJAX headers.
remove_filter( 'qm/outputter/headers', 'register_qm_output_headers_overview', 10 );

// Disable all PHP Error collecting in QM
define( 'QM_DISABLE_ERROR_HANDLER', true );

How you handle this is likely project-specific though, since it's likely you won't want to clobber all the debug info.

[kmgalanakis]

@darylldoyle thank you for your response. The problem in my case is not related to Query Monitor. It's caused by the server-side render method of a 10up-built custom block.

There has got to be a server configuration that should eliminate this error, but I'm not aware of it.

[darylldoyle]

@kmgalanakis can I ask, do you have Query Monitor active on the site? I've also seen this issue most often when SSR blocks in the block editor. It's usually because that rendering is done via an AJAX request and QM is adding a bunch of debugging notices/warnings to the headers.

If you've not got QM enabled on the site, then I'd suggest following the instructions within the link you sent, around increasing the Proxy Buffers. This can be done within the config/nginx/default.conf in your project. I've had mixed luck with these updates though.

[kmgalanakis]

@darylldoyle No I don't have Query Monitor active on my site. If I'm not wrong, I already tried the suggestions I found on that site and it didn't work, but I will try again. Thank you

[benlk]

I've also had this problem on AJAX, with and without QM.

My issue was that the AJAX call was creating an obscene amount of PHP errors and warnings and logs, which when written to the WordPress debut log approached 1MB of text per page load.

My suggestion is:

1. Empty your error log file
2. Run just that single request
3. Examine the error log to see all the errors; patch them until the request generates no error messages or logs

If these logs are coming from a 10up-maintained plugin or component, make sure you're on the latest version, and please file a bug for that code if you have the time.

[nicoladj77]

what usually solves this for me is

error_reporting(0);

as the last possible statement

[kmgalanakis]

As I said before, I had this error in the global reverse proxy log. Also, the error was caused by a large block's server-side render request. Apparently there were no PHP errors in my logs because the request was not even reaching the site server.

What eventually resolved the issue for me was to add in my reverse proxy server's nginx.tmpl here the following lines.

proxy_busy_buffers_size 512k;
proxy_buffers 4 512k;
proxy_buffer_size 256k;

based on the suggestions from this site about the fix when Nginx is running in a proxy / reverse proxy mode.

It's really weird for me the fact that I had to change proxy buffer size while the proxy buffer was set to off a couple of lines above. I'm not an expert though, so I'm still happy that it worked.

Thank you all for your suggestions.