Forum Moderators: phranque

Message Too Old, No Replies

Request exceeded the limit of 10 internal redirects due to probable co

         

csdude55

12:47 am on Dec 7, 2023 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I’m seeing a ton of these errors in my error_log (breaks added for readability):

[Wed Dec 06 13:17:52.158205 2023] [core:error] [pid 7247:tid 47778602907392] 
[client 123.45.67.89:0]
AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error.
Use 'LimitInternalRecursion' to increase the limit if necessary.
Use 'LogLevel debug' to get a backtrace.


As you can see, the error doesn’t tell me a domain name or page that’s creating the problem :-/

I have 212 accounts on my server, so it's darn nigh impossible to just look around at every page to see if there's a problem.

Any suggestions on figuring out where it might be originating?

phranque

2:06 am on Dec 7, 2023 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



i would turn on "LogLevel debug" until you get another failure and see if that trace provides any clues in the server error log.

lucy24

2:48 am on Dec 7, 2023 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



As you can see, the error doesn’t tell me a domain name or page that’s creating the problem
But it does tell you a time and IP, which can be cross-checked against access logs. (Not, ahem, manually. Shove them all into whatever bin they normally live in, and fire up something that will do a multi-file search.)

One possible, embarrassingly simple cause of this specific problem is if a request is blocked and you forgot to poke a hole for your custom 403 page. 8000 guesses how I know this.

csdude55

6:10 am on Dec 7, 2023 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



@phranque, I turned on LogLevel debug and had 56M of errors inside of 5 minutes :-O So I had to turn that back off fast! I did find the issue, though... sorta.

One possible, embarrassingly simple cause of this specific problem is if a request is blocked and you forgot to poke a hole for your custom 403 page.

Great minds think alike :-D

I found this in the error log:

[Thu Dec 07 00:29:28.536915 2023] [ssl:debug] [pid 30384:tid 47956824733440] ssl_engine_kernel.c(422): [client 192.241.84.4:0] AH02034: Initial (No.1) HTTPS request received for child 17 (server myserver.com:443)
[Thu Dec 07 00:29:28.538402 2023] [core:error] [pid 30384:tid 47956824733440] [client 192.241.84.4:0] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
[Thu Dec 07 00:29:28.538465 2023] [core:debug] [pid 30384:tid 47956824733440] core.c(3943): [client 192.241.84.4:0] AH00121: r->uri = /403.shtml
[Thu Dec 07 00:29:28.538481 2023] [core:debug] [pid 30384:tid 47956824733440] core.c(3950): [client 192.241.84.4:0] AH00122: redirected from r->uri = /403.shtml
[Thu Dec 07 00:29:28.538507 2023] [core:debug] [pid 30384:tid 47956824733440] core.c(3950): [client 192.241.84.4:0] AH00122: redirected from r->uri = /403.shtml
[Thu Dec 07 00:29:28.538522 2023] [core:debug] [pid 30384:tid 47956824733440] core.c(3950): [client 192.241.84.4:0] AH00122: redirected from r->uri = /403.shtml
[Thu Dec 07 00:29:28.538535 2023] [core:debug] [pid 30384:tid 47956824733440] core.c(3950): [client 192.241.84.4:0] AH00122: redirected from r->uri = /403.shtml
[Thu Dec 07 00:29:28.538547 2023] [core:debug] [pid 30384:tid 47956824733440] core.c(3950): [client 192.241.84.4:0] AH00122: redirected from r->uri = /403.shtml
[Thu Dec 07 00:29:28.538558 2023] [core:debug] [pid 30384:tid 47956824733440] core.c(3950): [client 192.241.84.4:0] AH00122: redirected from r->uri = /403.shtml
[Thu Dec 07 00:29:28.538570 2023] [core:debug] [pid 30384:tid 47956824733440] core.c(3950): [client 192.241.84.4:0] AH00122: redirected from r->uri = /403.shtml
[Thu Dec 07 00:29:28.538581 2023] [core:debug] [pid 30384:tid 47956824733440] core.c(3950): [client 192.241.84.4:0] AH00122: redirected from r->uri = /403.shtml
[Thu Dec 07 00:29:28.538593 2023] [core:debug] [pid 30384:tid 47956824733440] core.c(3950): [client 192.241.84.4:0] AH00122: redirected from r->uri = /403.shtml
[Thu Dec 07 00:29:28.538605 2023] [core:debug] [pid 30384:tid 47956824733440] core.c(3950): [client 192.241.84.4:0] AH00122: redirected from r->uri = /foo/bar

That's verbatim, except for the last /foo/bar. I don't mind leaving their IP in because it's almost definitely a bad actor, and any of this info might help someone find the answer in search engines :-)

First thing I did was check /foo/bar (no domain specified didn't help, but at least I was able to track that down) and it worked fine for me, so this had to be a rule set up in my Apache config. I use [F] a lot on known exploits, but I don't specify an ErrorDocument for 403 so I guess it's defaulting to 403.shtml.

I created a plain text 403.shtml file, but 40 seconds later I had another of the same error.

So next I added this as the very first rule in my Apache config:

RewriteCond %{REQUEST_URI} ^/403.shtml
RewriteRule ^ - [L]

It's been 15 minutes and no error, where I was getting at least 1 per minute! So that feels like a pretty good sign :-)

lucy24

5:19 pm on Dec 7, 2023 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



There you go :)

But it's more efficient to say simply
RewriteRule ^403\.shtml - [L]
Never put something in a Condition that can go in the body of the rule.

What, never?
No, never.
What, never?
Well, hardly ever.

The . should also be escaped, but in this context it's a far-from-lethal error.

csdude55

6:36 pm on Dec 7, 2023 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Haha, forgive me, that was 2am coding ;-P

I DID have a few more of the errors overnight, but since I'm using Cloudflare it's possible that they're coming from CF caching. I might dig further, but at least it's mostly resolved. Next up, I'm fielding tons of warnings from mod_pagespeed! I might end up removing it entirely, but that's a whole 'nother topic.