This works fine, status 200 and I see the content.
If that were the case, it wouldn’t work on the standalone.
Even so, it’s an SSL error, this is before headers matter.
Have you changed anything in the settings.js file for NR? You can also try deleting the http node, deploy, drag out a new one. Other than that, I don’t know of anything else to try.
No, I did compare it now with the standalone but I don’t see anything strange or related to this issue.
I also never changed the standalone nodered settings.js.
Tried removing and adding but same error 
I don’t think it will be a different outcome but you can use an exec node. Use curl like you would on a command line.
curl works in exec… so what does this even mean?
Is nodered missing a package or something?
Or why does it say ssl3_read_bytes:tlsv1, I reckon it’s not using 1.2+ or some reason? but I don’t where I can configure that.
Experiencing similar issues here. Started happening after migrating to a new host (ubuntu 24.04) and updating nodered (to v3.1.9). Not sure which of the two actions could have caused it. Only http request work. Even for a website like google.com.
One cause to the error message might be missing SNI data when connection to a multi-host web server.
https://www.cloudflare.com/learning/ssl/what-is-sni/
So, this problem is not only with the http requests but also e-mailing
Error: D8594C9BFD7E0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:…/deps/openssl/openssl/ssl/record/ssl3_record.c:354:
This is definitely a name lookup issue.
Either with SNI data in your request or your DNS service in you Node Red setup.
DNS is not the issue.
SNI data… I mean ok, who can fix that? As it works in a standalone NodeRed docker…
I think this is related to the way HAOS layers containers. According to the docs NR addon uses/ssh for cert location and that can’t be changed. For example, when using shell commands, you need to create new certs in the config folder for them to work.
How does this apply here, I’m not sure. What you can do is download wire shark and monitor your HA IP and make the request. IIRC bounced https requests will be highlighted in black. You will be able to see what was sent and what the response was, from that you should be able to see exactly what is going on.
Edit: I am assuming that the HA stores ssl certs in the same location/level as the ssh certs, which is not accessible when running commands.
How is this related to cert location?
Even if it was, than curl wouldn’t work as well, which it does.
And even if I see what happens in wireshark, I’m not going to be able to fix it.
So who do I talk to? or where?
I surmise that he OP was able to use the exec node successfully, while the request node failed, because the request came from NR container. The http request possibly goes through HA, a different container, different ssl and that’s why it failed.
As far as wire shark, if the problem is definitely because of that, you may need to see if it can be done from a command line/exec node. Otherwise track down whatever error you actually have.
Exec is still on the NR container. Just outside NR itself.
So it must be the build of NR that is the issue I reckon.
But who do I contact regarding this issue, who makes the NR container addon?
I don’t know that it is a bug but more of a feature. HA addons are protected by home assistant’s auth. I need to stress I do not know if this is the case, I am basing this off my experience with setting up shell commands.
What possible feature would that be, disabling the ability to make a secure connection…
It’s just unclear to me where I go with this issue
I was sufficiently interested to give this a go myself; you never know, I might learn something.
Even the forum editor returns error 403 (forbidden).
On my Raspberry Pi (Node RED v4 fully updated)
On my secondary Home Assistant, Node-RED addon v18 fully updated
On my primary Home Assistant, Node-RED addon v17 not yet updated
I am in the UK and have no problem with .eu sites.
I do not have the Node-RED Addon SSL turned on.
Is there supposed to be an error here?
Well yes. I now even tried local addresses with ssl and it’s the same thing.
Even my home assistant https url fails
BUT, then I tried a non existing local name… same error… what?
What is this sorcery? Where is it trying to connect 
And fyi, my hass nodes in nodered connect via my full fqdn homeassistant url over ssl…
NoderRed 4.0.2
Addon 18.0.4
I am certainly no expert in any of this, and for the most part I just use Node-RED and let it get on with the magic of doing what it does. Hence my apologies to anyone who is offended by my ignorance displayed as follows:-
However, I am slowly getting to understand more and more about how HA works, how Node-RED works, and how everything hangs together. At times I am quite surprised that any of this stuff actually works at all. Hats off to the developers!
First up, I suspect that the root cause of your issue is
and I would expect this to be as an export of flow, and subsequent import of flows, however you may have been tempted to just copy the ‘files’ across, thus bringing prior code or settings that may be specific to the old environment.
I have also grown to be wary of any badly behaved contrib-nodes, as these are reasonably well known for causing such things as editor issues. Everything in the palette has to be up to date. Bad nodes will cause the editor to fail to load, run, or disable bits and pieces.
The basic error you have certainly points to a DNS or name lookup issue, as Wally says, SNI data or DNS service. So, where do these happen?
As a fully supervised system, Home Assistant and Node-RED are run in docker containers. The Supervisor comes up first in its own container, then it brings up HA in another, and Node-RED in yet another. Containers are isolated and programmes can’t talk to each other, so they have to use a proxy server running in the Supervisor container. The system also runs a DNS server, and offers ‘supervisor’ as the host server by name.
The WebSocket nodes (which you say are working) are all connected back to HA using WebSocket and API calls, which for NR as an Addon I think use ‘supervisor:8123’ and must DNS and proxy via the Supervisor, Host, and DNS server(s).
Node-RED, of course, runs a NGINX server of its own, which provides all the API calls for the editor client.
So the question both you and I have is, when we use the http request node, where does the request go to? On a stand-alone NR installation I would still expect some form of proxy between the ‘flow execution of the node’ and the outside world. When NR is run as an addon, then it would expect further proxy handling of the request to get out of the container back to the outside world. How does Node-RED inherently support http requests?
After that, I have gone digging into the http request node code, which is a core node so can be easily found on the NR github repository.
module.exports = async function(RED) {
"use strict";
const { getProxyForUrl, parseUrl } = require('./lib/proxyHelper');
const { got } = await import('got')
const {CookieJar} = require("tough-cookie");
const { HttpProxyAgent, HttpsProxyAgent } = require('hpagent');
const FormData = require('form-data');
const { v4: uuid } = require('uuid');
const crypto = require('crypto');
const URL = require("url").URL
const http = require("http")
const https = require("https")
var mustache = require("mustache");
var querystring = require("querystring");
var cookie = require("cookie");
var hashSum = require("hash-sum");
// Cache a reference to the existing https.request function
// so we can compare later to see if an old agent-base instance
// has been required.
// This is generally okay as the core nodes are required before
// any contrib nodes. Where it will fail is if the agent-base module
// is required via the settings file or outside of Node-RED before it
// is started.
// If there are other modules that patch the function, they will get undone
// as well. Not much we can do about that right now. Patching core
// functions is bad.
const HTTPS_MODULE = require("https");
const HTTPS_REQUEST = HTTPS_MODULE.request;
function checkNodeAgentPatch() {
if (HTTPS_MODULE.request !== HTTPS_REQUEST && HTTPS_MODULE.request.length === 2) {
RED.log.warn(`
---------------------------------------------------------------------
Patched https.request function detected. This will break the
HTTP Request node. The original code has now been restored.
This is likely caused by a contrib node including an old version of
the 'agent-base@<5.0.0' module.
You can identify what node is at fault by running:
npm list agent-base
in your Node-RED user directory (${RED.settings.userDir}).
---------------------------------------------------------------------
`);
HTTPS_MODULE.request = HTTPS_REQUEST
}
}
Now I am not going to claim to understand very much of this stuff, however I can see that
- the node is using proxyHelper, hpagent, uuid etc as libraries to do action the htpp(s) work
- all modules are ‘required’ and therefore pulled in to the Node-RED module folder
- there is a great big error / warning about a patched https.request function
The text talks about issues where a corrupt agent-base module is ‘required’ by the settings file or from outside Node-RED before NR is started (or where a contrib nodes gets loaded before the core nodes and gets the wrong module that way).
Note the warning message (I wonder if you see this on start up?) and the cause (contrib node including old version of ‘agent-base@<5.0.0’ module) and how to find the faulty node.
After that, the specific error message ssl3_read_bytes:tlsv1 unrecognized shows up in Google searches. This one
https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2742
focuses on the nginx proxy manager (which I guess has quite a bit to do with Node-RED acting as the proxy) and how port forwarding can cause issues. Again, not something I know much about, but if you have any ports forwarded from your router… The difference between stand-alone NR and HA Addon is that, I assume, NR on its own using nginx to proxy out to the world. As Addon, nginx acts as proxy to the HA Supervisor, and in all of this, the SNI does not manage to decode qualified URLs, so setting a server name as an IP address causes a fail [would someone please explain that back to me? Thanks!]
Frenck does the Addon build. All the code is at
https://github.com/hassio-addons/addon-node-red
although I think that this is just a package of Node-RED with some HA extras and customised configuration.
If you want to dig into Node-RED itself regarding the error, there may be no better way than to talk to the Node-RED development team. I note on the GitHub repro for the http request node that Steve-mcl has recently been working on the code for this particular node. I don’t use the Node-RED forum often, but I have the impression that he is a regular contributor / part of the dev team for Node-RED and I am sure you can find him and ask him nicely if he would be able to assist you further.