This:
Server wouldn't respond
Server returned an Apache test page
Server couldn't be found
is not something I can particularly address. This list is a variety of different configurations and settings and behaviors. What's the current state of your server here?
In general... If you've been working here for a while and have been making changes to various settings as I'd infer, then I'd suggest wiping and reinstalling. Your configuration is probably skewed from what is the default and possibly from what is typical, as I can infer you probably don't have a full-disk backup prior to your changes and you probably also haven't saved off files and such and then re-set from any changes you've tried that haven't worked; that your current server configuration has diverged from the default configuration, and that there are now some tests and changes scattered through the current settings. These sorts of environments are exceedingly difficult to debug via forum postings.
(We all tend to make this diverging-from-defaults mistake, too. If you've make this mistake sometime in the past and have been resetting changes and configuration files back to the original settings after your tests, then please ignore this. I tend to use a target-practice server for this sort of experimentation, so I can test and change and then wipe and reload. I either load an existing configuration as the starting point, or I load a clean install.)
And in general, I'd suggest splitting up big questions (and this is a big question) into smaller hunks, and working through each of the invididual hunks.
This question has various different parts, with the following technical areas involved:
- IP routing.
- DNS services on your LAN, and DNS services external to your LAN.
- Apache virtual hosting.
- MySQL.
Again, if this is a skewed configuration, I'd suggest a reinstall. Get the server into a known state.
Off the top, and paralleling the above list...
- Get your IP routing sorted out. This is a prerequisite to the rest of the stack. If IP routing doesn't work, then DNS will be wonky, and the rest of the stack won't work right. I'd suggest use of an IP gateway firewall device (and preferably with server-grade features, though an Airport Extreme or a Time Capsule port-forwarding NAT widget can work for low-end cases) and don't try to use the Mac server box as an IP router. Test in-bound IP routing with the ping tool and with the telnet client (telnet to port 80, for instance, to test the web server path). (Don't start out in the 192.168.0.0/24 or 192.168.1.0/24 blocks, as those subnets will cause problems for IP routing with your eventual use of VPNs)
- Once basic IP routing is working, then get DNS services set up on the LAN, and then get your external DNS services set up at your ISP or DNS provider. Your internal DNS has your local IP addresses on your NAT'd LAN. This step is not optional; Mac OS X Server needs DNS for stable operations, and you CANNOT use your ISP DNS or any other external DNS for LAN-based DNS services activity with your (likely) NAT'd LAN.
- Set up one entry in your Sites entry using Server Admin, aimed at a static IP index.html page, and get that working. Most of Server Admin web set-up is the default, but make sure you don't have alias entries around unless you need them, and (when you have multiple Sites) watch out for any wildcard entry as that'll be the site that gets served when the DNS domain names or IP addresses (however you're referring to your virtual hosts) doesn't match a Site that's listed in your local set-up.
- Use the defaults. Create the database using Server Admin. Create the databases manually, using the MySQL command tools. The MySQL command line operations for database creation and granting database privileges and such work the same on Mac OS X Server as most everywhere else. If you're not familiar with the command line management of MySQL, then get yourself a copy of the (free) Sequel Pro tool. While working in this area, some folks will want and will install the phpmysql tool - if you do that, make certain your web server security does not permit that to be accessible to any remote sites, as the botnets are very fond of looking for and then attempting to breach that tool.
- Asking smaller and less sweeping questions tends to produce questions that are more easily answerable without writing a treatise in server and network and DNS and MySQL management, and doesn't expect or doesn't require somebody to be familiar with the whole collection of topic areas that you might be asking about.
