Unlike some rumors on the internet claim, there should be no need for exhausting configuration work to just test apt-cacher-ng and run it with default parameters. It's actually designed to bootstrap most of its working environment without additional help.
The package setup scripts used by distributions should already prepare working initial settings for apt-cacher-ng. Check the file /etc/apt-cacher-ng/acng.conf file where most settings are explained. For the beginning they should not be changed, the only interesting setting present there is the TCP port. See Advanced Server Configuration for details.
There is also a daily cron job which executes some maintenance work. Additional automated control commands can be added by administrator.
From the client side, apt-cacher-ng can be used as a drop-in replacement for apt-cacher. The same rules apply, e.g. Debian/Ubuntu users should EITHER:
http_proxy or (permanently) in some configuration file or dialog. For APT, this means putting a line like the following into a file like /etc/apt/apt.conf.d/02proxy:
Acquire::http::proxy "http://CacheServerIp:3142";
OR:
deb http://ftp.uni-kl.de/debian etch main
should now become:
deb http://192.168.0.17:3142/ftp.uni-kl.de/debian etch main
(assuming that CacheServerIp is 192.168.0.17 and the service port is 3142).
These both methods have their own pros and cons. The last method can be used with clients which cannot configure an additional http proxy for some reason. The disadvantages are the worse progress visibility (all downloads seem to come from the same machine) and some resource usage limits might be hit (i.e. maximum number of simultaneous downloads from the "same" machine). It might also require to modify many different URLs and some of those URLs might be hardcoded in software and not be accessible to the user.
The former method is more convenient since it usually means less configuration work; however, it implies that all relevant client programs respect the proxy setting and use it from this central location.
Mixing the configuration methods is usually possible but not within the same client program instance. Doing that (going with proxy mode AND use rewritten URLs) will probably confuse the server: in best-case, the connection will be slower because of a little transport loop on the server side, and in the worst-case, the target URL will eventually become not resolvable and the downloads will just fail.
Using SSL/TLS transport (i.e. https urls) is also possible with some restrictions, see section 8.3 for details.