[Looking for Charlie's main web site?]

Fixing CF: "Hey, how come ColdFusion debugging output is not showing up in my localhost testing?"

This is a problem that has troubled many CF users for some years (especially as they have moved to later operating systems): they find that ColdFusion debugging output does NOT appear to them when testing using a URL with "localhost" for the domain name but it DOES appear if they use the ip address instead.

And sure, they could change to just using the ip address, but they wonder why it fails with "localhost" and whether they can fix things so that it does? In this post, I offer the explanation and solution.

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
  • One option could be to edit your hosts file to force, 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 you will find that if you try that, it will change to "0:0:0:0:0:0:0:1", which does not solve this problem. I have a workaround for that, editing the neo-debug.xml.
Adobe could fix that last problem (and I have filed a bug report, CF-4203295), but until they do, here's a workaround and explanation of things.

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.

The workaround of editing neo-debug.xml

Until Adobe fixes that issue, 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.)


<struct type="coldfusion.server.ConfigMap"><var name="iplist"><string>,0:0:0:0:0:0:0:1</string></var></struct>

would become:

<struct type="coldfusion.server.ConfigMap"><var name="iplist"><string>,0:0:0:0:0:0:0:1,::1</string></var></struct>

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 (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:

<cfdump var="#cgi#">

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 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 (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: localhost

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:

<cfsetting showdebugoutput="no">

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


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.

# Posted By Animesh Dutta | 8/24/18 10:25 PM
The easiest solution is just to open your hosts file and put localhost

This acts as a local DNS proxy and redirects all requests for "localhost" to

This actually solves quite a few other issues with using localhost that have plagued folks for years, not just CF related.
# Posted By Russ | 8/25/18 3:05 AM
Thanks, Russ. I had indeed mentioned the option of editing the hosts file and showed the value to use. But I saw on review that I had made a mistake in the value I showed, so I have corrected that. You didn't indicate seeing that but I do thank you for mentioning this and causing me to correct that.

I also tweaked the opening to make it more clear that that's an option (in the "in brief" section--which I added with you in mind, as I know you tend not to like "all the waffle".)

Again, though, "the waffle" is more for the matter of our need (for now) to edit the neo-debug.xml because CF doesn't accept adding the ::1 address for us. That's the real problem I wanted to point out, and how editing that file is a workaround, and the challenges with that.

And as I also noted later in the post, editing the hosts file does not always suit everyone. In the forum thread where this came up (mentioned in my bug report), a poster expressed that editing the hosts file had not worked for him. Again, I alluded to some of the possible challenges with that and decided not to make this a post about that but about the CF issue instead.

Still, again I have tweaked the post a bit based on your comment and I thank you for that.
# Posted By Charlie Arehart | 8/25/18 7:34 AM
Copyright ©2018 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting