You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Chrome DevTools not able to connect to Node inspect since 7.5.0 #11591
Platform: Linux nodeServer 2.6.32-573.el6.x86_64 deps: update openssl to 1.0.1j #1 SMP Thu Jul 23 15:44:03 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux (VM) on Windows 10
Subsystem: Debugger
When I run a script with --inspect, I am no longer able to connect via Chrome DevTools since Node 7.5.0. When I attempt to connect I get "Debugging connection was closed. Reason: WebSocket disconnected Reconnect when ready by reopening DevTools" Clicking reconnect DevTools does not reconnect."
Simple script:
> node --inspect=8080 -e "setTimeout(function() { console.log('yes'); }, 30000)"
Debugger listening on port 8080.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:8080/e7cadd27-e1d6-42d3-8c53-c407dd543ec5
If I perform those steps on Node 7.4.0, it works. If I do the same steps in Node 7.5.0 or 7.6.0, the URL will no longer connect. I have the same results if I utilize Chrome 56.0.2924.87 or Canary 58.0.3025.0 on Windows.
I've also seen this. Debugging seems to work locally but not remotely. This also affects --debug as well as --inspect. For example, in node 7.6.0 I can node debug on the host running node, but cannot node debug server_name:5858 from another host. If I downgrade to 7.4.0 I am able to connect to the debugger remotely.
Reacted by Austin, Xaqron, Aleksander Nesterov, Kevin Schmidt and Mundoi
I suspect #9691 is responsible. It harmonizes option parsing with the old debugger but it presumably changed the default from 0.0.0.0 to 127.0.0.1 (although I'm 80% sure that was the default for --debug already.)
I'd say it's a good thing, security-wise. You can opt-out with --debug=0.0.0.0:5858 or --inspect=0.0.0.0:9229.
Reacted by Bastien, Tanakom, Dan Peng, Andrew Huff, Spencer, Will Prater, Denis Hilt, Jerome Shapiro, Aarón Rosas, Amos Yuen and 36 more
Reacted by ant45de, sboys3, LauItachi, Maximilian Meyer, Nitay Rabinovich and Cristian Mota
Reacted by Dan Peng, Denis Hilt, Aarón Rosas, Fabian Lauer, 尼库桑, Nik Katalnikov, Will, Denys Nykula, Safi, Petry DeChamp Richardson and 9 more
Reacted by Safi, Petry DeChamp Richardson, JDR, Senica Gonzalez, ant45de, Glavin Wiechert, LauItachi, Umut Özdemir, Magnus Österlund, Oleg Rakovich and 2 more
Reacted by Maximilian Meyer, idken, André Kuhlmann and Cristian Mota
Sounds like the debug port is bound to localhost by default now, since opening it to remote connections allows remote attackers unfettered access, but I don't see signs of this in the changelog.
But there should be a way to change the default if its explicitly wanted.
@sam-github
As @bnoordhuis pointed out, you can specify an IP address to listen on. Inspector is still an "experimental feature" so I did not think that this bugfix needed to be reflected in a change list...
It was an unexpected change in how node behaves, it should have been documented. Experimental doesn't mean "we don't tell you when we changed it, post a github issue if you'd like to know more". I don't think it means "we reserve the right to make breaking changes in minor updates" either. cc: @Trott
I think the change to default to localhost is a good one, but I'm not sure it should have happened before 8.x (though security fixes are allowed to majors even when breaking, the CTC has the power to give them special exemptions).
Btw, something is wrong here: https://github.com/nodejs/node/pull/9691/files shows zero changes in the diff, and no commits, but also says its merged. I haven't seen that before in github, it sure makes it hard to review the PR retroactively to see what was merged.
I can confirm --debug=0.0.0.0:5858 does allow for remote debugging again in 7.6.0. I see why the change is beneficial from a security standpoint, but I wish there had been some docs for this change. It would have saved several cycles trying to track down why remote debugging stopped working.
While the --debug pathway might work, I'm not sure if there is a way to get the --inspect pathway as it stands on 7.60. I've tested a couple different variants. Looking at the code in the commit, it was altered to use host pretty much everywhere, but if you look at the original code, sometimes it was 0.0.0.0 and othertimes it was 127.0.0.1. Well with the host var it's using the same value everywhere, even though previously it was 2 distinct values. In example the URL that was spit out always contained 127.0.0.1 but then the there was the line for uv_ip4_addr("0.0.0.0", port_, &addr); which had 0.0.0.0 hardcoded.
I've tried variants of passing --inspect=0.0.0.0:8080 and using the URL given back as well as altering the url to contain 127.0.0.1:8080. I've also tried the opposite where I pass --inspect=127.0.0.1:8080 and use the URL or switch the url to be 0.0.0.0:8080. None of the attempts work. Some of them will "connect" but it's a weird state where I'm not able to actually get to any of the sources files, or interact with anything, but it's not giving me the disconnection error.
If someone has figured out a proper set of steps to use --inspect or --debug but connect via Chrome, I'm happy to use it as a work-around. For now we've just reverted back to 7.4.0 in the meantime.
I don't think remote debugging was tested enough. I am assigning this over to me - I see issues like json/list returning 0.0.0.0 as a host name (should be detected), I also expect other similar problems.
I also experience issues with --inspect since version v7.5.0. When I install v7.4.0 the inspector works just fine. As soon as I install v7.5.0 or higher the inspector ends with empty sources, i.e. no files are present. Sometimes if I wait long enough the files in sources appear. Still I am not able to set any breakpoint in the files. To me something went really bad between version 7.4.0 and 7.5.0...
Make sure to publish ports, otherwise connection refused: docker-compose run --rm --service-ports node bash
Verified using "localhost" instead of 0.0.0.0, but --inspect-brk=0.0.0.0:9229 works as well!
bash-4.3# node --inspect-brk=localhost:9229 index.js
Debugger listening on ws://localhost:9229/33dc4d2a-7a17-47ac-bf64-f66329d60872
For help see https://nodejs.org/en/docs/inspector
Debugger attached.
To debug a node.js service in a docker stack from the Chrome DevTools locally you need to configure
the listening port of the debugger with the long syntax and the inspect parameter as @nsisodiya said :
@bnoordhuis Dude, you saved me!!! I spent 3 hours trying to figure out why my inspectors wouldn't work. I knew it had mostly to do with me running via docker. But the bind to 0.0.0.0 solved it!!!! You rock!
Can't debug live.
This alert pops up every time I try to save a file. What's that? It's not possible to debug/develop when debugger doesn't reload automatically
I use nodemon to reload my node.js server. My config for it:
Oh My Lord @bnoordhuis, I try node --inspect-brk xx.js for 4days' debugging without any work.
Finally !!! node --inspect=0.0.0.0:9229 --inspect-brk xx.js works!!!
Reacted by irdy, Donncha Breen, Alfian Busyro, Magnus Österlund, ZackZhang and jing-appsynth
I am using puppeteer to launch headless chrome. The problem with me is that I can't use a static port.
The application is being used by multiple users. Each users have to have a chrome browser open to themselves. So I need to expose multiple ports in docker. but it needs to be dynamic.
Current setup is a VM hosted on VMWare using NAT and port 9229 forwarded from VM to host.
NodeJs is v8.10 and Chrome is v71 and the below command works
Activity
mscdex commentedon Feb 27, 2017
/cc @nodejs/v8-inspector
brantw commentedon Feb 28, 2017
I've also seen this. Debugging seems to work locally but not remotely. This also affects
--debugas well as--inspect. For example, in node 7.6.0 I cannode debugon the host running node, but cannotnode debug server_name:5858from another host. If I downgrade to 7.4.0 I am able to connect to the debugger remotely.bnoordhuis commentedon Feb 28, 2017
I suspect #9691 is responsible. It harmonizes option parsing with the old debugger but it presumably changed the default from 0.0.0.0 to 127.0.0.1 (although I'm 80% sure that was the default for
--debugalready.)I'd say it's a good thing, security-wise. You can opt-out with
--debug=0.0.0.0:5858or--inspect=0.0.0.0:9229.sam-github commentedon Feb 28, 2017
Sounds like the debug port is bound to localhost by default now, since opening it to remote connections allows remote attackers unfettered access, but I don't see signs of this in the changelog.
But there should be a way to change the default if its explicitly wanted.
@ofrobots, do you know anything about this?
eugeneo commentedon Feb 28, 2017
@sam-github
As @bnoordhuis pointed out, you can specify an IP address to listen on. Inspector is still an "experimental feature" so I did not think that this bugfix needed to be reflected in a change list...
sam-github commentedon Feb 28, 2017
My comments and Ben's crossed on the wire.
It was an unexpected change in how node behaves, it should have been documented. Experimental doesn't mean "we don't tell you when we changed it, post a github issue if you'd like to know more". I don't think it means "we reserve the right to make breaking changes in minor updates" either. cc: @Trott
I think the change to default to localhost is a good one, but I'm not sure it should have happened before 8.x (though security fixes are allowed to majors even when breaking, the CTC has the power to give them special exemptions).
Btw, something is wrong here: https://github.com/nodejs/node/pull/9691/files shows zero changes in the diff, and no commits, but also says its merged. I haven't seen that before in github, it sure makes it hard to review the PR retroactively to see what was merged.
@eugeneo any idea what is going on with the PR?
eugeneo commentedon Feb 28, 2017
I am not sure what had happened to the pull request display - the actual commit can be seen here - f9aadfb
But it looks like the change is really this one - #10878
brantw commentedon Feb 28, 2017
I can confirm
--debug=0.0.0.0:5858does allow for remote debugging again in 7.6.0. I see why the change is beneficial from a security standpoint, but I wish there had been some docs for this change. It would have saved several cycles trying to track down why remote debugging stopped working.sam-github commentedon Feb 28, 2017
@eugeneo can you PR some docs for the current state, something saying what address is listened on by default?
owenallenaz commentedon Mar 1, 2017
While the
--debugpathway might work, I'm not sure if there is a way to get the--inspectpathway as it stands on 7.60. I've tested a couple different variants. Looking at the code in the commit, it was altered to usehostpretty much everywhere, but if you look at the original code, sometimes it was0.0.0.0and othertimes it was127.0.0.1. Well with thehostvar it's using the same value everywhere, even though previously it was 2 distinct values. In example the URL that was spit out always contained127.0.0.1but then the there was the line foruv_ip4_addr("0.0.0.0", port_, &addr);which had 0.0.0.0 hardcoded.I've tried variants of passing
--inspect=0.0.0.0:8080and using the URL given back as well as altering the url to contain 127.0.0.1:8080. I've also tried the opposite where I pass--inspect=127.0.0.1:8080and use the URL or switch the url to be0.0.0.0:8080. None of the attempts work. Some of them will "connect" but it's a weird state where I'm not able to actually get to any of the sources files, or interact with anything, but it's not giving me the disconnection error.If someone has figured out a proper set of steps to use
--inspector--debugbut connect via Chrome, I'm happy to use it as a work-around. For now we've just reverted back to 7.4.0 in the meantime.eugeneo commentedon Mar 1, 2017
I don't think remote debugging was tested enough. I am assigning this over to me - I see issues like json/list returning 0.0.0.0 as a host name (should be detected), I also expect other similar problems.
oldrich-s commentedon Mar 5, 2017
I also experience issues with
--inspectsince version v7.5.0. When I install v7.4.0 the inspector works just fine. As soon as I install v7.5.0 or higher the inspector ends with emptysources, i.e. no files are present. Sometimes if I wait long enough the files insourcesappear. Still I am not able to set any breakpoint in the files. To me something went really bad between version 7.4.0 and 7.5.0...sam-github commentedon Mar 6, 2017
It sounds like an unintended semver-major occurred between 7.4 .and 7.5, should it be reverted? @nodejs/ctc
Change was:
Which is particularly problematic because there seems to be a (unrelated?) bug in the inspect option:
8 remaining items
kenny-reyes commentedon Jun 2, 2017
This works for me @nsisodiya.
Thanks
AlexanderAllen commentedon Jun 9, 2017
Took a while to get this working.
Confirmed that @nsisodiya solution works.
Docker Compose
Make sure to publish ports, otherwise connection refused:
docker-compose run --rm --service-ports node bashVerified using "localhost" instead of 0.0.0.0, but
--inspect-brk=0.0.0.0:9229works as well!On Chrome:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/14b1c01b-e7f4-40e2-8b59-e914b38209d1I'm using the Node.js V8 --inspector Manager (NiM) Chrome plugin as well to get to the chrome-devtools address.
sheetaldubey commentedon Jul 8, 2017
i have node 7.4.0 and i am using mac. As I am starting node server in debug mode
node --debug server.js
The server starts successfully by giving message as Debugger listening on 127.0.0.1:5858
but my chrome not able to load 127.0.0.1:5858.
Any workaround for this.?
bnoordhuis commentedon Jul 8, 2017
@sheetaldubey
--inspect, not--debug. Also, you should probably upgrade to the latest v7.x or v8.x release.MohammedEssehemy commentedon Jul 15, 2017
Thanks @nsisodiya
PopradiArpad commentedon Oct 13, 2017
To debug a node.js service in a docker stack from the Chrome DevTools locally you need to configure
the listening port of the debugger with the long syntax and the inspect parameter as @nsisodiya said :
That's all...chrome://inspect will be able to detect the listening debugger as usual.
Remarks:
attachable.localhost. Use 127.0.0.1 instead.danielo515 commentedon Nov 15, 2017
How can I activate remote debugging it on an already running process when I activate the debug protocol by using
kill -s SIGUSR1?dechamp commentedon Nov 16, 2017
@bnoordhuis Dude, you saved me!!! I spent 3 hours trying to figure out why my inspectors wouldn't work. I knew it had mostly to do with me running via docker. But the bind to 0.0.0.0 solved it!!!! You rock!
wzup commentedon Dec 27, 2017
Can't debug live.
This alert pops up every time I try to save a file. What's that? It's not possible to debug/develop when debugger doesn't reload automatically
I use
nodemonto reload my node.js server. My config for it:Chrome 63.0.3239.108 (Official Build) (64-bit)
Node v6.11.5
Windows 10 64x
JeffML commentedon May 11, 2018
Got this working. In package.json:
Then run
npm run debug-remoteand on my local box, go to node-inspector:
chrome://inspect/#devicesadd (via configure) the remote device:
172.00.00.00:9229// replace IP with real remote IP addressSave it, and the remote target list should give you a connection link. Click it and you're good to go.
MagikLau commentedon Jul 14, 2018
Oh My Lord @bnoordhuis, I try node --inspect-brk xx.js for 4days' debugging without any work.
Finally !!!
node --inspect=0.0.0.0:9229 --inspect-brk xx.jsworks!!!softmantk commentedon Jul 22, 2018
I am using puppeteer to launch headless chrome. The problem with me is that I can't use a static port.
The application is being used by multiple users. Each users have to have a chrome browser open to themselves. So I need to expose multiple ports in docker. but it needs to be dynamic.
Adds support to provide host/port for the -I (inspect) argument.
creativesoftwaregun commentedon Jan 21, 2019
Current setup is a VM hosted on VMWare using NAT and port 9229 forwarded from VM to host.
NodeJs is v8.10 and Chrome is v71 and the below command works
node --inspect-brk=0.0.0.0:9229 sample_debug.js
thanks to @bnoordhuis @nsisodiya
fzhange commentedon Dec 8, 2020
use node inspect ./index.js in node 12. it works