Note: This blog post is from 2018. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

TLDR (and update since initial post):
If you can add ::1 to the list of debugging IP addresses in the CF Admin, that should solve this problem. If you cannot, that problem was fixed a few months after I wrote this, in CF2018 update 2 and CF2016 update 8, released in Feb 2019 (and it's no longer a problem on CF2021 and above, of course). For those not yet running those, if you find that adding ::1 just turns into 0:0:0:0:0:0:0:1, read on.

For more on the matter, including why it happened, solving it, etc., read on.

Of course, one "solution" is that someone COULD just "get used to" using that 127.0.0.1 ip address for all their local requests, but they may wonder why it fails with "localhost". Let me explain.

In brief, the problem happens when the OS you're working on processes your "localhost" request via ipv6 (if it makes the request as ::1), rather than ipv4 (as 127.0.0.1).

• One option could be to edit your hosts file to force 127.0.0.1, and that should work
• But another would be that if you knew about your localhost calling with the ipv6 address of ::1, you should be able to add that to your CF Admin "debugging ip addresses list" (or use its "add current") button. But (at least before the CF2018 and CF2016 updates mentioned above) you will find that if you try to do that, the CF Admin will change the value to "0:0:0:0:0:0:0:1", which does not solve this problem. I have a workaround for that below, editing the neo-debug.xml.

Adobe could fix that last problem and I have filed a bug report, CF-4203295.

And this latter point, of the inability of the Admin to accept ::1--and on the matter of editing that file--is the real focus of this post (at least as written originally in 2018, I mean).

The workaround of editing neo-debug.xml

A workaround is for you to edit the neo-debug.xml file for your CF setup.

If you're going to do that, make a copy of the file first, which is found in the [cf]\cfusion\lib folder). Then in the original file, find the "iplist" value (which lists any debugging ip addresses that have been added in the CF Admin). Add "::1" to the list there.

If there are other IP addresses already there, separate it from the others with a comma. (See below for much more on all this.)

So:

would become:

Save that change, restart CF, and test things. If it works, great. If not, there some more things you can consider. (And you can restore that saved file to get you going again if you made a mistake.)

For more on the matter, read on.

So what gives?

Well, the issue first is that your OS is translating your use of "localhost" in URL to be not 127.0.0.1 (or 0:0:0:0:0:0:0:1), but instead your OS is translating that (and passing to CF) the ipv6 value of ::1.

You can confirm this yourself if you create and run a CF template on your local machine that does:

You will find that the value shown for the "remote_addr" in the CGI scope is ::1. That's the conversion of your localhost request into that IP as it arrives at the server.

And again the second issue is that THAT is what CF receives and compares to the ColdFusion Admin "debugging ip addresses list", and for some reason (even in CF2018, and earlier) if you put in "::1" as a value in that field, it converts it to 0:0:0:0:0:0:0:1. (And you may find that that and 127.0.0.1 are already there).

Again, I have filed a bug report for this problem. Please go add your vote and/or comments to it.

(Another thing you could try, to confirm the nature of the problem, would be to go to the command line on your OS and do a "ping localhost" to see how that resolves. I don't want to elaborate here about how to do either of those things, so I leave that info for more experienced users it may benefit.)

Aren't there other solutions/workarounds?

Well, yes. Again, as I said at the opening, you can just change from using localhost to using 127.0.0.1 (or 0:0:0:0:0:0:0:1) as the IP address in your URL.

But if you want to still use "localhost", another solution it to edit your hosts file to add the value:

That could work as well, or it may not (people's experiences vary, and can have as much to do with challenges like whether your browser picks up that change without a browser restart, and more).

And there could be benefits for you to make that change beyond this CF problem, or there may be detriments (such as if something else is EXPECTING it to resolve to ::1). My focus here in the post is really about the problem with the inability of the CF admin to just add the value ::1 in the "debugging IP addresses" field, and this option to manually edit the neo-debug.xml file. (And you'll see I conclude with one more problem that could be causing the problem in the title of this post.)

About editing that neo-debug.xml file

There are a few challenges you may hit when trying to edit this neo-debug.xml file.

Where do you find the file?

So first, as for where you find the neo-debug.xml file (and other neo-*.xml files, which hold your CF admin setting changes), that is located in the lib folder for your CF instance.

If you are on CF10 or above, and are using just the one instance that comes with CF, that's in your CF folder's cfusion/lib directory. If you have created an instance, then it's in the CF [instancename]/lib folder.

If you are on CF9 or earlier, in a typical "server" deployment it will be in your CF folder's lib directory. If using the multi-server (multiple instance) form of deployment it will instead be buried deep in the jrun4 folder, such as [JRun4]\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\ for the initial cfusion instance, or look for your instancename under the jrun4/servers folder to find the files for a given instance.

What if you can't save changes to the file?

You may find that upon making the change to the file as I propose above that when you try to save the changes, you cannot. This is typically a problem that happens when someone else has installed CF, and the CF folder has been set to allow THEM to edit files there, but not you. There are a few solutions to resolve this (which deserve their own blog post), but just quickly, try saving the file somewhere that you CAN save it. And then see if you can copy the file over to the "real" location. Often that copy mechanism will offer to let the copy happen (asking for confirmation) even when the editor would NOT make the same offer.

And please note my warning that you save first a copy of that neo-debug.xml file (any CF admin xml file) before trying to edit it. If you make a mistake (even removing just a single slash by mistake), you may find that the related feature in the admin won't work, or in some cases CF may not even start or run properly.

What if it's "still not working" for you?

If you may argue that "this still doesn't work" for you, please check first that dump of the CGI scope which I proposed that you run, in code that you call using that localhost URL. What is the cgi.remote_addr value?

Whatever it is, that value needs to be added to the debugging ip address list. Indeed, if it's anything but the ::1 value discussed here, you can just go to the CF Admin "debugging ip addresses" page and use the "add current" option there to cause CF to put whatever it detects (in that cgi.remote_addr field) into the debugging IP address list for you. It's only because it WON'T do that for the ::1 value (currently) that I needed to write this post.

"I just can't get CF debugging output to show up at all"

Perhaps you're having a problem getting CF debugging output to show at all. Maybe you found this post and have read all this way and tried ALL the above--and you STILL find that your debug output doesn't show up.

In that case, make sure that the problem isn't simply that you have code turning off debugging output. As you may know, there is a CF tag to do that:

Now, if you look in your template and don't find it, note first that it might be done using another value besides "no": it could also be "off" or "false" or "0", etc. Second, note that one can set multiple attributes on a CFSETTING tags. Finally, it could be done in cfscript (so not a cfsetting tag but a setting statement). So you can't just "look for that tag" above. You COULD look for "showdebugoutput".

Finally, even if you don't find that at all in your template being tested, note that of course such code disabling debugging may be set in some OTHER template, whether the application.cfm or cfc that controls your app, or in some file your code includes or otherwise invokes. (You can use a better file search tool, perhaps one in your editor, to search all *.cf* templates for "debugoutput". I will note that I have written before about my favorite free file search tool.)

If you either don't want to search all your code, or find that you can't, here is a sanity check you can do to confirm if THAT may be the problem or not: just create a new folder within your web app (call it "test" or something), and in THAT folder put your code to do just the cfdump above, and then ALSO put in that folder a blank application.cfm file. That will stop CF from looking in any parent or ancestor directory for one. Run the test page, and see what whether you see any debugging output below the dump output.

If you DO now see debug output, then something in your "real" code really WAS turning off debugging, as it's clearly working on your server. If you do NOT see debug output, then something very odd is going on (and I can help with that, if you don't get Adobe or others to help).

Conclusion

I hope that helps get you going, and not just "the least you needed to know" (which I offered first). Too often, people want or seek (or offer) only that "least one needs to know" and find that gets the into trouble or they are left hanging, since there are all these little vagaries which that could keep things from "just working" for you.

And as you can tell, I've seen all these problems before. All I do all day is help people troubleshoot problems with CF (and other CF engines and other Java app servers). If you ever face problems and want someone to look into the problem with you and solve it (and who not only can anticipate all these extra things you may need to know but also show you how to understand and resolve such problems yourself), that's what I do in my remote short-term consulting. See my consulting page for more on my approach, rates, satisfaction guarantee, and more.

I welcome your feedback on the solution here.

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed