#ERR_SSL_WRONG_VERSION_NUMBER for GET Requests behind an https load balancer

40 messages · Page 1 of 1 (latest)

fluid moss
#

Hi everyone, I am currently running v13.5.5-canary.7 and all server side GET requests running in standalone behind an https load balancer results in the following error:

export const GET = async (req: Request) => { 
    ...
    return new Response(res, {
    status: 200,
    headers: {
      'content-type': 'application/xml',
      'cache-control': 's-maxage=31556952',
    },
  });
}

TypeError: fetch failed at Object.fetch (node:internal/deps/undici/undici:13220:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
cause: [Error: 185CCA705E3E0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:354:] 
{
    library: 'SSL routines',
    reason: 'wrong version number',
    code: 'ERR_SSL_WRONG_VERSION_NUMBER'
}

I had previously seen this same error with next/images however that was resolved in a v13.5.x build. Is anyone else facing this issue?

olive sinewBOT
#
Post created!

🔎 This post has been indexed in our web forum and will be seen by search engines so other users can find it outside Discord

🕵️ Your user profile is private by default and won't be visible to users outside Discord, if you want to be visible in the web forum you can add the "Public Profile" role in id:customize

✅ You can mark a message as the answer for your post with Right click -> Apps -> Mark Solution
(if you don't see the option, try refreshing Discord with Ctrl + R)

wide lagoon
#

what is the node version you are running

#

ssl error normally only happens when you are running old node

#

make sure you are on node 18.x

fluid moss
#

This also happening for v13.5.4 and v13.5.3

#

I am running node:20-alpine

#

I believe that maps to 20.8.0

wide lagoon
#

im running newest node just fine. Its more likely you have not added the required libssl needed

#

make a codesandbox showing the same error. if you cannot, it is your container. alpine linux has extreme differences in configuration complexity for all types of runtimes and requires more knowledge to maintain.

fluid moss
wide lagoon
fluid moss
#

I'm not entirely sure how to go about creating a codesandbox for a server running behind a proxy / load balancer. The endpoint is accessible locally, just not behind an https proxy / load balancer. When running this via GCP's Cloud Run, I have been seeing this error

wide lagoon
#

That directly infers that it is your configuation. if it works locally/on vercel and doesnt behind some config you have done outside of nextjs, it is not a nextjs issue. If it is in fact the issue in the github issue linked, then that is the place to address it.

Feel free to leave the help request open but im just warning you that the chances of it being resolved here are slim from the current info

fluid moss
wide lagoon
random juniper
#

I'm also having this issue right now

#

upstream image response failed for /_next/static/media/CallToActionBackground.6bf2a67e.png TypeError: fetch failed

library: 'SSL routines',
reason: 'wrong version number',
code: 'ERR_SSL_WRONG_VERSION_NUMBER'

#

Node 20.8.0 as well

#

@fluid moss it's also bricking my website completely, you can't access it at all when this error occurs

#

only solution is to do npm run build and redeploy it

#

it's really a massive burden this issue

fluid moss
#

@random juniper yeah :/ fortunately for me its just one non critical endpoint so I still have my app in production with a todo to resolve it at a later date. I saw your posts in the github thread. Thanks for escalating it. Looks like some folks are having more luck with certain canary builds but Im just going to wait it out for now

random juniper
#

Good news, the issue is now being tracked by maintainers

random juniper
#

emphasis on might

#

That x-forwarded-* headers fix was linked to the issue @fluid moss

random juniper
#

@fluid moss Try canary 16, it's too early to say but I think the issue is fixed with the revert drop ipc headers fix

fluid moss
#

Thanks! I am going to wait for the final 13.5.5 release to roll out but I appreciate the heads up. Makes sense that it has to do with the headers not propagating through

random juniper
#

@fluid moss It’s finally out! 🙌🏾

fluid moss
#

nice, Ill try it out later today! Thanks

fluid moss
#

looks like my specific issue is still there with 13.5.5 :/

random juniper
fluid moss
#

yeah my setup is a bit different though, I use gcp http load balancers that inject headers to a gcp cloud run container running in http, It’s a bit of a black box with networking for me tbh but I think the problem is there

errant harness
#

Did everyone get this solved? I'm having basically the same problem when using a custom server, and I see upstream image response failed for /layers.png TypeError: fetch failed in the logs

#

A few other notes:

  • I'm using Node 20. Are people who are seeing this using Node 18 or Node 20?
  • I'm hosting my app on Heroku
  • The error I'm seeing mentions port 3000, but that is likely not the port it's running on Heroku, and I don't use port 3000 locally, either. Is there any setting that encourages things to run on port 3000? Here's a bit of that snippet of the error:
upstream image response failed for /MyLogoFileName.png TypeError: fetch failed
 at Object.fetch (node:internal/deps/undici/undici:11413:11)
 at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
...
cause: Error: connect ECONNREFUSED 127.0.0.1:3000
2023-11-09T23:50:52.862837+00:00 app[web.1]: at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16)
 at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
 errno: -111,
 code: 'ECONNREFUSED',
 syscall: 'connect',
 address: '127.0.0.1',
 port: 3000
}
random juniper