Binding Apache to a Specific Or Secondary IP Address

Apache, by default, will attempt to bind to and listen on these interfaces:


1. “” means ALL IPv4 addresses that the system has (including

2. “::” means ALL IPv6 addresses that the system has (including ::1).

When started, Apache will try to take all the IP addresses of the system, and if you are already running another web-server (such as IIS, Tomcat, Nginx, Jetty, Domino, etc) on that same system, Apache will not be able to bind to “” and “::”, and will fail to start. Or, if started first, after binding to all the available IP addresses, it will prevent the other web-server form starting.

To bind Apache to a specific or secondary IP address:

Edit file –

Find and replace these two lines (one is at the beginning, the other at the end) –

Listen 80
Listen 443

With –


You can specify multiple IP addresses with multiple lines.

If this is a public server, make sure that the IP addresses you are using, are either the resolvable IP addresses of your Apache hosted domain names (e.g., the Public IP address), or the LAN IP addresses that the Router is port-forwarding outside port 80 and 443 traffic to.

If this is a intranet server, you can just bind Apache to the LAN IP.

If this is a localhost server, you can just bind Apache to

Also make sure that your other web-server is binding only to a specific IP address, and not to “”.

After making changes, if Apache won’t start, check the configuration by running (from the command line):

httpd -t -n "Apache2"
httpd -k start -n "Apache2"

Upgrading WampDeveloper Simplified

The upgrade process for 95% of WampDeveloper users involves (for the most part) just copying and replacing a few folders and files to keep your previous websites and databases.

The process in the larger WampDeveloper Upgrade guide appears more complicated because it includes additional explanations, takes care of special cases, and describes possible issues (with solutions provided).

This is the simple version of the WampDeveloper Upgrade guide. If you are upgrading between versions within the same major version or branch, and have not made any significant changes to the configuration and the platform, this guide is for you.

Upgrading WampDeveloper

  1. Click uninstall (bottom of Components Tab), proceed.
  2. Rename folder C:\WampDeveloper to C:\WampDeveloper.old
  3. Install new version as C:\WampDeveloper
  4. If you have websites and databases to keep:
    1. Using the Websites Tab, re-create your extra (new) websites (by inputting the same domain name and domain aliases for each website). Then stop Apache and MySQL.
    2. Delete and replace (with previous) folder: \Database
    3. Overwrite / copy-over (with previous) folder: \Websites
    4. Re-install the phpmyadmin database by using (i.e., copy-paste + update for drive letter) and running the 4 commands listed in the section “Re-Install phpMyAdmin’s Database” of the larger guide.
  5. If you used WampDeveloper to auto-install web-apps (via Webapps Tab), to see those web-app installations listed in the Webapps Tab, replace (with previous) file: \Webapps\apps.xml
  6. If you have made custom changes to the website VirtualHost files, website AWStats configuration files, and/or the general Apache, MySQL, and PHP configuration files – those changes should be made again in the new installation.

Error “Warning: mysql_pconnect(): MySQL server has gone away…”

If you are having a reoccurring problem where Mysql refuses connections with the following error message:

Warning: mysql_pconnect(): MySQL server has gone away in C:\WampDeveloper\Websites\\webroot\script\file.php on line X

Note that you are using persistent connections. Persistent connections do not automatically close when the script ends, and likely what is happening is either…

  1. That same persistent connection, is correctly reused each time the script runs, but eventually it does reach its maximum run-time value, and is closed by MySQL. And only after your page is refreshed/reloaded and the script runs again, a new persistent connection is created and everything works again (until the next timeout).
  2. Many persistent connections are created, and after MySQL reaches the maximum number of allowed connections, no new connections are allowed until some of the previous connections timeout. Sometimes this is due to a large number of users (100+) all accessing the script, other times this is due to issues and bugs in the script itself (and there can also be some complications when running PHP-FCGI).

To fix this, you have several different options:

Default to Regular Connections

Tell PHP to silently use non-persistent connections even when persistent connections are specified…

Edit php.ini (C:\WampDeveloper\Config\Php\) and update or add this into the [MySQL] section…

; Allow or prevent persistent links.

This will close each connection when the script ends, regardless if “mysql_pconnect” or “mysql_connect” is used.

Switch to Regular Connections

Don’t use the persistent versions of PHP functions and methods for MySQL connections. Persistent connections are never recommended, and should only be used in special circumstances (because they tend to just cause connection exhaustion while offering no real performance gains).

Instead of “mysql_pconnect” just use “mysql_connect“. Both functions use the same exact API (i.e., parameters), and you can safely search-and-replace all occurrences of “mysql_pconnect(” with “mysql_connect(” in your script files.

Also note that the above functions are depreciated starting with PHP 5.5, and will be removed from PHP in later versions. If you can, switch to using PDO methods.

Increase Max Connections and Timeout Values

Otherwise, increase the number of allowed connections…

Edit my.ini (C:\WampDeveloper\Config\Mysql\) and add this into the [mysqld] section…

Increase the number of MySQL connections allowed:

max_connections = 151

* The above is the default value.

Depending on the situation, decrease the persistent connection timeout value (so those persistent connections are closed and recycled faster):

interactive_timeout = 28800
wait_timeout = 28800

* The above are the default values, in seconds (8 hours).

These settings might not exist in my.ini, you have to add them into the [mysqld] section of the file.

Note that:

1. These are the default values for each setting… If you put them “as-is”, they will have no effect… As those settings + values, even while they might not be present in my.ini, are already set by default by MySQL for itself on each start-up.

2. These values don’t technically fix anything, they just try to mitigate around some underlining problems with connection timeouts caused by issues in the script. They are temporary patchwork (in most cases).

3. Take care setting these values correctly. max_connections might need to be doubled, and/or the timeout value might need to be lowered to 300 (seconds). But if you increase or decrease these values too much, other issues could start happening.

4. Don’t use these settings if they do not fix anything.

5. You’ll need to restart Apache and MySQL after making changes to my.ini and php.ini.

Installing APC for PHP 5.5 and 5.6

If you need to install and enable the php_apc extension for PHP 5.5 or 5.6, there is a way to accomplish this. But before you do this, there are a few things you have to be aware of:

  1. The last PHP version that had the php_apc extension included in was PHP 5.3. * Newer versions of PHP have replaced APC with php_opcache.
  2. The last APC release was php_apc 3.1.14, and while it worked with PHP 5.5, it was immediately removed due to some serious memory issues that could not be fixed. * php_apc 3.1.14 is not available anywhere, it was removed from all official sources.
  3. The only available release of APC is 3.1.13, and while it’s for both PHP 5.3 and 5.4, it’s only non-beta for 5.3 (i.e., not recommended for PHP 5.4).* php_apc 3.1.13 will not work with PHP 5.5+.

Having said that, APC has two parts to it…

  • The opcode cache part that compiles and caches script code.
  • And the data cache part that stores key/value pairs (e.g., just like memcached).

If your scripts require APC, more than likely they only do so because they use APC’s data cache part. And if you want to run those scripts under PHP 5.5 or 5.6, the APCu extension fully replaces APC, and is fully compatible with APC’s API.

APCu is the APC extension with the opcode cache part removed (which was the source of all APC issues) and the data cache part cleaned up. APCu has the same exact functions and configuration directives as APC – so it can be used as a drop-in replacement.

Also, from what I’ve gathered, APCu performs even better than memcache/memcached on single server setups (which is the case 95% of the time if you are using a WAMP such as WampDeveloper Pro).

Installing APCu For PHP 5.5

1. Download the latest build of APCu from –

For PHP 5.5 Standard:

For PHP 5.5 FCGI:

2. Extract out files php_apcu.dll and php_apcu.pdb into the proper PHP version package –

For PHP 5.5 Standard:


For PHP 5.5 FCGI:


3. Edit php.ini, near end add section:


3. Save file. Restart Apache.

Assigning a Dedicated IP Address to a Website

There are only several situations where you would need to assign and dedicate an IP address to a website on the web-server’s end.

Under normal circumstances, you can host 100s of websites, each using its own separate domain name and aliases, on the same exact single IP address – without having to directly assign a specific IP address to a website (on the web-server’s end).

Once you assign a dedicated IP address to a website, any requests that come in on that IP address, will return only that specific website, regardless of the domain name used, and you will not be able to host other websites without an additional IP address.

Domain Based Hosting Vs IP Based Hosting

All URL requests (i.e., HTTP/1.1 requests) made by Browsers carry additional information in them, such as the “Host” Header, that the web-server can read. This “Host” Header specifies the requested domain name.

With modern Apache configurations (such as provided by WampDeveloper Pro), the way it works is that Apache reads the “Host” Header from the incoming request to get the domain name, and returns the proper website by matching that domain name to one of the websites Primary Domain Name or Domain Aliases… That is, once the request reaches Apache, no IP addresses are used to select a website.

Using Domain Based Hosting, after you set up DNS for your domain names, everything else is taken care of automatically…

When a request from a Browser is made, the DNS system will resolve the domain name to an IP address, and the request will travel and route though the internet using that IP address, but when it reaches WampDeveloper Pro, Apache will simply read the “Host” Header (that is part of that incoming request) to get the domain name, and will then return the proper website (by matching that domain name with one of the websites).

To set up DNS, using the DNS control panel of your Registrar or DNS provider, assign each domain-name (including the “www” part, the base domain part, and any aliases) an IP address via an “A” record. Then wait an hour for the global DNS system to update.

IP Based Hosting

There are several edge-cases and situations where Domain Based Hosting does not work 100% for everyone:

1. HTTP/1.0 requests do not contain the “Host” Header, which was introduced in HTTP/1.1. Some older or very simple programs, scripts, and bots, that visit or send requests to your website might still use HTTP/1.0 (or they just might make a direct connection without using DNS). In which case Apache will return the default (first loaded) website instead of the correct website.

2. Very old versions of Browsers (e.g., IE6) do not support SNI (Server Name Indication). And when those Browsers make an HTTPS request, since the “Host” Header is only decrypted and read after the SSL connection is established, Apache has no choice but to return the default (first loaded) website’s SSL certificate instead of the proper website’s SSL certificate. And the user is presented with a certificate mismatch warning and/or is prevented (for security reasons) from loading the website by the Browser.

3. Related to #2, aside from IE6, all versions of IE on Windows XP and Server 2003, Safari on XP, and some other earlier versions of other Browsers do not have native support for SNI, relying on the OS’s implementation of it. And Windows XP and Server 2003 did not provide an implementation of the needed system component for SNI.

4. Users, configuration policies, and some installed programs (such as McAfee) are able to disable some SSL and TLS protocol versions (on Windows), or their SNI extension, and occasionally do so for unknown reasons. Any Browser that does not use its own integrated implementation of the needed components will not be able to make an SNI enabled request in this situation.

Assigning a Dedicated IP Address to a Website

Edit the website’s HTTP and HTTPS VirtualHost files.

* Select your website in WampDeveloper’s Websites Tab, click the HTTP and HTTPS VirtualHost button.

Update this:

<VirtualHost *:80>

With this:


Save files. Restart Apache.

PHP And Mysql Error ‘TYPE=MyISAM’ With Failure To Install Php Script

If you install an older PHP script or application that was designed to use MySQL 5.1, under MySQL 5.5 or 5.6, this error will either be displayed on-screen or will be logged in the website’s PHP or MySQL error log files.

#1064 – You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘TYPE=MyISAM’ at line …

MyISAM in MySQL 5.5+

The MyISAM storage engine is still available in ALL versions of MySQL, including 5.5 an 5.6 (and can also be used as the default storage engine).

The only things that have changed from MySQL 5.1 is that:

  1. InnoDB is used IF the table type is not explicitly specified when the table is created.
  2. The SQL syntax was changed from "TYPE=" to "ENGINE="

Fixing ‘TYPE=MyISAM’ MySQL Error

Your issue is a result of depreciated SQL syntax being used that is no longer valid in MySQL 5.5+.

MySQL 5.5+ no longer uses keyword "TYPE" to specify the database engine to use for the table (e.g., InnoDB, MyISAM). MySQL 5.5+ uses the keyword "ENGINE" instead.

To fix the broken PHP script or application, edit the files manually, or use an editor like Notepad++, to search and replace in all the *.sql files (or in *.php files if it’s generating the DB dynamically in some function), and change all occurrences of "TYPE=" to "ENGINE=".

Usually you only have to edit 1 SQL or PHP file, that is used to create the database on installation.

Default Storage Engine MyISAM

If your PHP script or application depends on MyISAM (for whatever reason), AND it does not specify the ENGINE type when creating new databases and tables…

Edit MySQL 5.5+’s my.ini file to change MySQL back to using MyISAM by default…


Otherwise the InnoDB storage engine will be used.

Other Incompatible Changes

While the majority of the issues will be solved with the above changes, there are also a number of other issues that can come up…

Upgrading from MySQL 5.1 to 5.5

For example, you should replace all occurrences of "TIMESTAMP(N)" with "TIMESTAMP".

Opening the MySQL shell, creating a test database, useing that database, and executing SOURCE C:/path/to/file.sql, will give you a good view of the issues in the SQL file – as it tries to create its tables.

If you import the MySQL data files instead of the SQL dumpfiles, make sure to also run ‘mysql_upgrade‘.

Netbeans “Waiting For Connection (netbeans-xdebug)” Issue

When NetBeans is unable to make a connection with XDebug, the NetBeans IDE will display message “Waiting For Connection (netbeans-xdebug)” at the bottom right corner…


Lets go through the list of things that can cause this issue.

* To save you all the reading, this issue is more than likely your firewall or anti-virus software blocking NetBeans from establishing a connection, or NetBeans attempting to connect with XDebug on something other than IP (through a LAN or Public IP, or on the IPv6 interface) and port 9000.

Check NetBeans Project Configuration

After configuring XDebug and setting up NetBeans to use the same local web server, check the Project settings to make sure everything is correct:



Check XDebug’s Loading and Configuration

Make sure XDebug has actually been loaded by PHP, and it’s settings are correct.


The important settings are these:


This tells XDebug to enable connections to it, and to send the data back to, which hopefully NetBeans is listening on.

Check Apache’s, PHP’s, and Website’s Error Logs

Check the specific website’s PHP error log file for any clues such as “unable to load module …” and “Call to undefined function …”.

Also check the general Apache and PHP error log files for the same messages or other errors.

* The PHP error log file will not exist if: you are using PHP-FCGI (in this case the errors are logged to each website’s individual PHP error log file), and/or no errors have been generated so far.

Check Browser

Does the URL (substitute in your domain name) come up without any issues?

If not, then possibly:

  • The Browser (or OS) is configured to use a Proxy which resolves the website’s Domain Name to somewhere else (i.g., not to
  • The Windows Hosts file might have the website’s Domain Name to IP resolve line missing, or using an IP other than

Make sure NetBeans is closed, and restart Apache, don’t start NetBeans. Does the full query URL come up without any issues?

If not, then possibly:

  • The website’s VirtualHost files or .htaccess file have redirect or rewrite rules that are breaking the request.

Check Rewrite and Redirect Rules

NetBeans will use a URL with a query similar to this:

Possible .htaccess and VirtualHost mod_rewrite rules that use, parse, and/or redirect requests based on the query string could break the request.

Clear Previous Sessions and Cache

Stop Apache, and delete all files in PHP’s and XDebug’s temporary folders:


This will clear out any previous sessions so you can start with a fresh PHP session store and a fresh XDebug data store. Sometimes these temp files get corrupted, or don’t get cleared out properly, and things get hung up.

Check Bindings

Make sure that another process or program has not taken

Close NetBeans, stop Apache, wait a minute for all the Listeners to clear out, then open the command line (admin mode), and execute:

netstat -o -n -a | findstr

If it finds a Local Address Listener (which is the 1st address, not the 2nd), you can cross-reference the PID (Process ID #) shown in Windows Task Manager, Processes Tab (click button: ‘Show processes from all users’ at bottom so it displays everything).

Whatever this turns out to be, it needs to be stopped and disabled, or re-configured to not take port 9000.

* The other option is to reconfigure both NetBeans and XDebug (php.ini) to use another port.

Check NetBeans Listeners and Connections

If the above is clear, verify that NetBeans is:

  1. Listening on all interfaces of IPv4 ( and IPv6 (“[::]”) with port 9000.
  2. Taking a connection on

Start Apache, open NetBeans, load your project, make a debug point in the PHP code, and click to Debug it.

Once this is started, NetBeans should create the proper Listeners, and if everything is correct, start talking back and forth with Apache (if PHP is type:Regular) or PHP (if PHP is type: FCGI) between port 9000 and some random port of the Apache / httpd or PHP process…

netstat -o -n -a | findstr :9000

A good debugging connection between NetBeans and Xdebug looks like this:

  TCP               LISTENING       5424
  TCP        ESTABLISHED     5424
  TCP         ESTABLISHED     6604
  TCP    [::]:9000              [::]:0                 LISTENING       5424

It shows that NetBeans (PID 5425) is Listening on all IPv4 addresses ( includes, and that there is a connection Established to and from Apache / httpd (PID 6604).

* Names of processes are shown in Windows Task Manager, Processes Tab (click button: ‘Show processes from all users’ at bottom so it displays everything).

The important part here is that NetBeans is at least Listening on Otherwise, its settings are wrong, or something (usually firewall and anti-virus software) is preventing it from starting that Listener.

Is NetBeans Using a Non-Default Port (not 9000)?

If NetBeans is not using the correct port (9000), update NetBeans settings:

Tools, Options, PHP, Debugger Port

Or update XDebug’s php.ini settings to match that port.

Is NetBeans Only Listening On IPv6?

If there is no proper IPv4 ( or Listener, verify that:

NetBeans, and Java, have NOT been configured to prefer (use) IPv6 over IPv4:

For NetBeans –

Global Configuration File:

C:\Program Files\NetBeans 8.x.x\etc\netbeans.conf

Local Configuration File (might not exist):


In option “netbeans_default_options” make sure it’s not set to prefer IPv6:

If it is, change it to:

For Java –


Control Panel - System - Advanced System Settings - System Properties - Advanced tab - Environment Variables

Check the environmental variables list for variable: _JAVA_OPTIONS

If it exists and contains:

Change it to:

Also open the Java Control Panel, and check if there are any Java Runtime Parameters (Java – View) or Proxy Settings (General – Network Settings) listed.

Control Panel - Java

* After these changes, reboot.


Make sure that NetBeans is working with IP, rather than the LAN IP or Public IP!

Otherwise, XDebug’s “xdebug.remote_host=” will need to either be updated with the specific IP, or “xdebug.remote_connect_back=1” used to tell XDebug to connect back to ANY source IP…

“If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP request. It checks the $_SERVER[‘REMOTE_ADDR’] variable to find out which IP address to use. Please note that there is no filter available, and anybody who can connect to the webserver will then be able to start a debugging session, even if their address does not match xdebug.remote_host.”


“When the URL variable XDEBUG_SESSION_START=name is appended to an URL Xdebug emits a cookie with the name “XDEBUG_SESSION” and as value the value of the XDEBUG_SESSION_START URL parameter.”

If there is an issue with cookies being set, “xdebug.remote_autostart=1” must be used…

“Normally you need to use a specific HTTP GET/POST variable to start remote debugging. When this setting is set to 1, Xdebug will always attempt to start a remote debugging session and try to connect to a client, even if the GET/POST/COOKIE variable was not present.”

Check Firewall and Anti-Virus Software

If the NetBeans project settings are correct, the website work in your Browser, the IPv4 Listener is good, it’s possible that your Firewall and/or Anti-virus software has decided to block the Java based NetBeans program from making connections, and possibly also Apache and PHP, and/or port 9000.

You’ll have to either shut them down, or go through their current lists of blocked and quarantined programs (NetBeans, Apache / httpd, PHP) and blocked ports (9000).

And also create rules and whitelists for NetBeans, and for port 9000.

I would start with McAfee and Kaspersky, by just turning then off (some of these don’t fully turn off and have to be uninstalled). Then check Windows Firewall the same way.

Also, just to cover the last crumb, right-click on the php_xdebug.dll file, select Properties, and if its listed as “Blocked”, click to unblock it:



For best results while figuring out the cause of all this, to bypass all the external browsers, in the NetBeans Project’s Properties, Browser category, switch from ‘Default’ or ‘Chrome’ to “Embedded WebKit Browser”.

Some questions to ask yourself –

1. Have any other Apache or PHP extensions been loaded? Apache’s mod_security could easily block this (it’s never loaded by default in WampDeveloper Pro). Some extra PHP extensions might also conflict with XDebug.

2. Where there any changes made to PHP’s php.ini, aside from introducing the XDebug section? And also Apache’s configuration?

3. Has the website’s VirtualHost files been modified with php.ini overriding settings (“php_value” or “php_admin_value” setting “xdebug.remote_host=some.where.else”), other configurations, or access restriction?

4. Has the website’s .htaccess file been modified with php.ini overriding settings (as above), other configurations, or access restriction?

5. Where any extra .htaccess files placed into any of the parent folders (from the website), all the way up to C:\ ?