enter image description hereApache in XAMPP not working I've searched and I found that I have to change port from 80 to 8080 and from 443 to 4433 and I did this and the same result I've tried another port but no change the same error
note : I'm not have skype
I tried to change port and uninstall XAMPP and reinstall and apache still not working
I'm on a really strange situation.
I'm using MAMP and I can't access to my working directory from the 127.0.0.1.
When I'm using localhost instead of 127.0.0.1 it works because the localhost is redirected to the ::1 ipv6 address.
So, I can access to my local server only via ipv6.
I've tried to start a little server with Python and it doesn't work ( it works fine on my personal laptop using OSX El Captain ).
When I try with an other port than 80 it works but I need to use this port ..
It's not a conflict, when I'm running the Python server he is the only one to listen the port 80
Do you have an idea about this trouble ?
Why I can use the ipv6 local address only ?
I have a vagrant box with xdebug installed, running on OSX, but Im struggling to get the Atom xdebug plugin (php-debug) to connect to it.
I pasted the phpinfo(); data into the xdebug validation site and it said all was good. And you can see all the xdebug settings.
I have mapped port 9000 in the vagrant file.
config.vm.network :forwarded_port, guest: 9000, host: 9000
The vagrant box has host only network that exposes 192.168.10.100 as the IP of the server.
And I've tried all manner of different xdebug options, the ones on the ATOM plugin site suggest..
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_connect_back=1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_autostart=true
But that is a slightly confusing as remote_connect_back=1 means xdebug will ignore the remote_host setting - so not sure why both are in there - neither work.
I've restarted apache / php after each time I change the options, and check they are loaded with phpinfo();
If I check who is listening on port 9000
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Atom\x20H 10656 Matt 28u IPv6 0x321cb0a96ba5b593 0t0 TCP *:cslistener (LISTEN)
VBoxHeadl 10889 Matt 19u IPv4 0x321cb0a981a71433 0t0 TCP *:cslistener (LISTEN)
You can see both vagrant (virtual box) and Atom. Although Atom is IPv6 which is odd....
But enabling the debugger in ATOM, setting a breakpoint and hitting the site, nothing happens - ATOM never connects.
Any ideas? Anyone got this to work?
But that is a slightly confusing as remote_connect_back=1 means xdebug will ignore the remote_host setting
You are correct -- that option is not needed there -- it better be set to 0
xdebug.remote_host=127.0.0.1
This is wrong (unless you will be doing debugging via SSH tunnel). It must be an IP where debug client (Atom in your case) is running. It's xdebug who connects to client and NOT other way around: https://xdebug.org/docs/remote
This also means that the IP must be as seen from that Vagrant machine. Possibly the easiest way of getting it -- look at what $_SERVER['REMOTE_ADDR'] has.
I have mapped port 9000 in the vagrant file.
config.vm.network :forwarded_port, guest: 9000, host: 9000
You do not need to expose 9000 port in Vagrant -- nobody will be connecting to it (like you do with port 80 for web server) -- it's xdebug from VM/guest OS will be connecting outside to your "real"/host OS.
If anything -- you should be allowing outgoing connections on that port instead of incoming.
If I check who is listening on port 9000
This one means that Atom is unable to receive incoming xdebug connection over TCPv4 .. which xdebug will try to use by default (unless you specify IPv6 address in xdebug.remote_host).
If anything -- collect xdebug log (xdebug.remote_log) and see where it tries to connect etc.
#LazyOne already answered this question, but issue I had was caused by antivirus (MCAfee) which was blocking incoming traffic. Maybe this will help someone in the future.
I have an EC2 instance which is running with the following security groups:
HTTP - TCP - 80 - 0.0.0.0/0
Custom UDP Rule - UDP - 1194 - 0.0.0.0/0
SSH - TCP - 22 - 0.0.0.0/0
Custom TCP Rule - TCP - 943 - 0.0.0.0/0
HTTPS - TCP - 443 - 0.0.0.0/0
However, when I try to access http://{PUBLIC_IP} or https://{PUBLIC_IP} in the browser, I get a "{IP} refused to connect" error. I'm new to AWS. Am I missing something here? What should I do to debug?
One way to debug this particular class of problem is to use netcat in order to determine where the problem lies.
If you run netcat against port 80 on the public IP address of your instance and just get a hang (no output at all), then most likely your security group isn't allowing traffic through. Here is an example from an EC2 instance that is in a security group that doesn't allow port 80 traffic inbound:
% nc -v 55.35.300.45 80
<just hangs>
Whereas if the security group is changed to allow port 80, but the EC2 instance doesn't have any process listening on port 80, you'll get the following:
% nc -v 55.35.300.45 80
nc: connectx to 52.38.300.43 port 80 (tcp) failed: Connection refused
Given that your browser gave you a similar "connection refused", most likely the problem is that there is no web server running on your instance. You can verify this by ssh'ing into the instance and seeing if you can connect to port 80 there:
ssh ec2-user#55.35.300.45
% nc -v localhost 80
nc: connect to localhost port 80 (tcp) failed: Connection refused
If you get something like the above, you're definitely not running a webserver.
I'm not sure if it's too late to help but I was stuck with a similar issue with my test server
SG Inbound: ssh -> 22
HTTP -> 80
NACL: default allow/deny settings
but still couldn't ping to the server from my browser, then I realize there's nothing running on the server that can serve the request, and I started httpd server (webserver) and it worked.
sudo yum -y install httpd
sudo service httpd start
this way you can test the connectivity if you are playing with SGs and NACLs and of course it's not the only way, just an example if you're figuring your System N/W out.
Have you installed webserver(ngingx/apache) to serve your requests. If so please share your the config files. (So that it will help to troubleshoot)
I think the reason is probably that you did not set up a web server for your EC2 instance, because if you try to access http://{PUBLIC_IP} or https://{PUBLIC_IP}, you need to have a background server to serve the http request as #Niranj Rajasekaran said.
By the way, by simply pinging the {PUBLIC_IP}, you could see if your connection to your EC2 instance is normal or not.
In command prompt or terminal, type
ping {PUBLIC_IP}
In my case, the server was running but available on just 127.0.0.1 so it refused connections from external hosts. To see if this is your situation, you can run
netstat -an | grep <port number>
If it says 127.0.0.1:<port number> instead of 0.0.0.0:<port number>, you have this problem.
Usually there's a flag or an argument in your server code somewhere to set the host to 0.0.0.0:
app.run(host='0.0.0.0') # flask example
However, in my case, I had already set this so I thought that couldn't possibly be the issue, which is how I ended up on this thread, which asks more generally about the problem. Unfortunately, I was using docker, and had set 0.0.0.0 on the container but was mapping that explicitly to 127.0.0.1 on the host in the docker-compose port-mapping:
ports:
- "127.0.0.1:<port number>:<port number>"
Changing that line to remove the host IP specification fixed the problem upon re-deploy:
ports:
- "<port number>:<port number>"
I have an instance Ubuntu 13 on EC2 of AWS
In that instance, in installed 2 applications on nginx with port 80 and 8080. I have also Tomcat running on port 8888.
I have penned theses port with AWS console -> Securit Group -> Inbound -> Custom TCP rule.
It worked well until last night for all port 80, 8080, 8888.
But this morning, i can't connect to the port 8888. I don't change any thing neither on my instace nor on console of AWS. I verify that wget localhost:8888 work well
Have you an idea to resolve this problem ?
Thank you in advanced.
Tien,