I am looking for a quick way to scan for commonly open ports on proxies. I am doing this through php and I have been using nmap and came up with this command:

system("nmap -PN -p U:1194,T:21,22,25,53,80,110,111,143,443,465,993,995,3306,8443,553,554,1080,3128,6515,6588,8000,8008,8080,8081,8088,8090,8118,8880,8909,1723,7080 {$_SERVER['REMOTE_ADDR']} 2>&1"); 

The problem is that it typically takes 1-2 seconds for the scans to complete, even if i just defined port 80, it's still around 1-2 seconds.

However doing this in PHP will return almost instant or timeout within 0.5 seconds:

    if( @fsockopen( $_SERVER['REMOTE_ADDR'], $port, $errstr, $errno, 0.5 ) )
    die("php_tests_callback({success: false, message: 'Client has port $port open'});");

So I am wondering if there is a more optimized way of using NMAP or an alternative program? I am almost tempted to write some sort of php forking process to run numerous fsockopens.


Apparently I need to read NMAP man before I post a question. I came up with these arguments which usually get the scan down to 0.50 seconds or a tad more.:

system("nmap -T5 --host-timeout 4s --min-rate 1000 -PN -p U:1194,T:21,22,25,53,80,110,111,143,443,465,993,995,3306,8443,553,554,1080,3128,6515,6588,8000,8008,8080,8081,8088,8090,8118,8880,8909,1723,7080 {$_SERVER['REMOTE_ADDR']} 2>&1"); 

However, I am still open to other suggestions/applications.

  • 4
    FYI, there's a nmap PHP wrapper, too.
    – sr_
    Jan 10, 2012 at 9:07
  • 1 single port with fsockopen takes 0.5 seconds ok. 30 ports with nmap takes 1-2 seconds. Which is faster?
    – Daniel W.
    Jun 18, 2014 at 9:12

3 Answers 3


Take a look at the Rainmap Web-hosted Nmap scanner. It was developed as a Google Summer of Code project 2 years ago under the guidance of the Nmap development team


Try using the -n option to disable DNS resolution.


Indeed -T5 --host-timeout is the right way to go.

The udp port scan might be the one slowing down the scan. You might fasten even more your scan by removing this port udp1194.

I might be wrong as the -T5 option may already cancel the udp scan because it takes too long.

As per 'Nmap Discovery Protocol' written by the nmap developer, I quote :

The other big challenge with UDP scanning is doing it quickly. Open and filtered ports rarely send any response, leaving Nmap to time out and then conduct retransmissions just in case the probe or response were lost. Closed ports are often an even bigger problem. They usually send back an ICMP port unreachable error. But unlike the RST packets sent by closed TCP ports in response to a SYN or connect scan, many hosts rate limit ICMP port unreachable messages by default. Linux and Solaris are particularly strict about this. For example, the Linux 2.4.20 kernel on Felix limits destination unreachable messages to one per second (in net/ ipv4 I icmp. c).

Scanning UDP ports is important because many vulnerable services use that protocol, but the timing characteristics and performance requirements of UDP scans are much different than TCP scans. Of particular concern is ICMP error rate-limiting, which is extremely common and affects UDP scans far more often than TCP. I don't recommend combining TCP and UDP scans when performance is critical.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.