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 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.