OK, I'm writing this down just in case I run into again the future, because I just spent HOURS tearing my hair out before finding the solution. Maybe it will help someone else someday, too. I recently messed around with a whole bunch of configuration-related stuff for my Google App Engine app, requiring me to reestablish my my Eclipse run configuration parameters for executing my app in the development server. In the past, I had set up port forwarding rules in my router, so that I could hit my app running in my dev server from remote clients like browsers running on other machines, from my client Android app, etc., and it had been working fine.

As is so often the case, after making configuration changes, there is a hill to be re-climbed in order to get everything working again. In my case, although I could access my app in the dev server from clients running on the same machine, my remote clients could not connect. I checked my port forwarding rules in my router -- they were still there. I tested them using PFPortCheck tool, and it verified the ports were forwarding correctly.

I turned off my firewall; nope, that's not the problem.

I rebooted. Nope.

I power cycled my router and my cable modem (obviously getting desperate here, since I'd already verified that port forwarding wasn't the issue, but I've also found that sometimes challenging your assumptions helps). But nope.

I tried different ports. I checked to make sure there weren't other apps listening on the same port and stealing the requests. Nope, nope.

I set up Fiddler in reverse-proxy mode, and get this -- it started working. That is, with my dev server listening to port 8080 (the forwarded port) and Fiddler listening on 8888 (also forwarded), my outside requests to 8888 were being picked up by Fiddler, rerouted to 127.0.0.1:8080, and successfully received by my app. Damn, a Heisenbug. OK, interesting, but still frustrating -- why did that work, and what does it tell me about the problem?

After much Googling and cursing, I eventually stumbled across the culprit. I needed to provide an "--address=..." argument in the run configuration's command line, to tell the server to listen for connections to addresses other than 127.0.0.1. After setting this argument to the value of my externally-visible IP address (see WhatsMyIP), I was back in business!

Ugh.

[follow-up: if you specify the --address argument as 0.0.0.0, you can connect from remote clients using the externally-visible IP address, and still connect locally using 127.0.0.1]