I understand the temptation to interpret the behaviour changes from 5.24.0 to 5.24.1 as suggesting that this is where to problem lies but often it isn't that clear-cut and I'd be surprised if this turned out to be a Perl version bug although it could possibly be tied to subtle behaviour changes for ambiguous code - seeing some code snippets may help rule this out.

I'd be more inclined to look at the dependent module version changes - try to update LWP and Crypt::SSL IO::Socket::SSL + Net::SSLeay etc to most recent available versions.

• Are you using strict and warnings?
• Can you isolate a failing case URL consistently or is this intermittent and not URL specific
• What are the MIME types of the responses? - eg are these file downloads or just plain text/html?
• Have you tested the URLs with other download approaches other than LWP (curl CLI or other Perl HTTP client? Possibly test with Mojo::UserAgent)
• Is the LWP Client running inside a docker container? Assume not but If so - What is the container O/S?
• Does the LWP Client process terminate after receiving a result - could it be terminating before processing the response or mishandling buffer flush?
• Are the LWP requests going to HTTP or HTTPS and is this consistent ?
• What versions of LWP etc are bundled with each Perl version? Perhaps also check whether the module path libraries are distinct and not shared.
• Have you confirmed this behaviour on Windows machines with only 5.24.0 installed and seen the behaviour rectify on a clean 5.24.1?

I'd first try use IO::Handle;OUT->autoflush(1) to see what happens.

May also be worth looking at the HTTP headers included both client and server-side as tightening the HTTP dialogue parameters may resolve.

Some small blocks of code that show the main LWP calls and a few lines of relevant log files could be useful to help others diagnose also