Setup and configuration

LocalProxy is designed to need no configuration 'out of the box'. However ...

If you get a recent version of the right configuration for your environment, use the GUI to select that configuration, 'start services', configure your browser/client appropriately (set the proxy/service it uses to localhost:10080 or whatever) and surf/read news/etc.

If there is no appropriate configuration for you, read on.
If you have no idea at all, and there's no provided configuration, or to get a configuration file as a starting point, try the 'AutoConfigure' button on the advanced window. Be prepared to wait for the firewall and proxy tests to complete.
You cannot do much damage to localProxy's operation by adding extra proxies at each layer (see below), so feel free to experiment. If you put many proxies in the configuration file, it will just take localProxy longer to learn which ones are good. Although localProxy is designed to work with many proxies, some bad, it will always help to start localProxy off with a good configuration. To do this, you need to understand how commStrats, and proxies configured are used by localProxy. Hopefully the following will make this clearer.

Services

A client application (maybe your web browser) connects to localProxy and makes a request. The port it connects to defines the service class (e.g. http proxy) and type it requires (standard, or anonymous, for example). The (service specific) commStrat and layer 0 proxy (and, when needed, the layer 1 proxy) for a particular request are all selected at random (preference to fast ones) from the lists provided in the distributed configuration, modified by your additional data in the config-<yours>.xml file.
Continuing the web browser request example, each component of a web page is a separate request as far as localProxy is concerned, so there are many paths (commStrat/layer 0 host/layer 1 host/) selected for each page for this service.

CommStrats

These are the strategies used to access the web site requested.

Layer 0

This is a list of hosts (proxies or redirectors usually) which localProxy will connect to directly.

Layer 1

This is a list of hosts (proxies usually) which will be used only by commStrat 1 (CONNECT via a layer 0 host). The layer 0 proxy is told to CONNECT to these layer 1 proxies and the browser then requests the web page directly from the layer 1 host (in the web browser example this is a proxy service; in other cases, it is most likely the required service directly (e.g. a news server:port)). See 'distributed' and 'normal' services in 'concepts', for an explanation of this.

When commStrat 1 is in use, the layer 0 host is in a 'pass through' mode.

The currently enabled list of commStrats is:
0. Requests from (and content returned to) your browser are unmodified (except in some HTTP error cases). This strategy is used with proxies you may be able to directly access (non-standard, unblocked port proxies, like 8000 for the UAE, or redirectors on an outside account). The proxies are connected to directly from localProxy (and so must be on unblocked ports). Redirectors on shell accounts which redirect connections to a blocked public proxy behave like a proxy, and so may also be used in this commStrat. There is no layer 1 set for this commStrat and the layer 0 proxy will make the request directly to the web site (redirected by a redirector if that's what the layer 0 host is).
1. 'CONNECT': The layer 0 proxy is connected to directly and requested to CONNECT to a layer 1 remote (standard, blocked port) proxy. In this mode, localProxy's operation is similar to HTTPort (but it will, in addition, 'fail over' to good proxies and prefer the faster ones).
2. 'Modified url': Similar to commStrat 0, but the URL requested is modified using various encoding techniques to bypass regexp censoring proxies, such as those in use in the Middle East. Modifications as simple as changing the case of a character can easily defeat the censoring in the UAE, for example, while other, more complex modifications defeat the censoring in the KSA. Most 'substrategies' of this strategy will not allow uncensored access if the censoring is based on the web site name - it's usually only good for the URL path (the stuff after the site name). For example, this commStrat will get you to my old (blocked) page: http://www.angelfire.com/wy/5waynes/software.html, because www.angelfire.com is not blocked, but it will take some time to learn to get you to http://www.sex.com/ because the blocking there is done on the site address. CommStrat 2 tries various forms of site name and path modification (32 bit address, hex encoding, octal encoding, Akamai-like requests etc., CGI proxies (including translation sites etc.)).

3, 4, 5 ... 9 Not implemented yet. 0 through 2 are all that is necessary for most ME users, but I will listen to requests.

Configuration

Configuration examples are provided for individual ISPs and countries (UAE, KSA). These should be mostly adequate for UAE and KSA. Other examples are provided to show how to customize them (User0, wayne-dialup) for different situations. New configurations for experimentation may be added by simply copying a config-<config name>.xml files to a new file config-<new config name>.xml.
User configuration should be done in the config-<configName>.xml files only.
The other *.xml files are the ones I will distribute with later releases and contain a basic data set used by all. These are:
At this time, I haven't incorporated a good XML editor, so you need to find your own. Web browsers do a good job of displaying these files (Internet Explorer is best), and Mozilla 0.9.5 (or better) is good for editing them. There are other free XML editors around as well. Most changes to the config files may even be done with a text editor (my favorite method).

User's proxies may be tested and added into a user configuration to make localProxy consider them for it's build. This may be done by using statProxy.pl and mergeHosts like this:
perl statProxy.pl -t all proxy1.emirates.net.ae:8080 > test.out
perl mergeHosts.pl test.out config-wayne-dialup.xml

(use your own proxies and configuration file, of course).

I prefer the command line approach above, but most users will probably prefer to do this by using the 'test and merge' field and button in the GUI, like this:
Select the configuration you wish to update
Enter the proxies you have in the appropriately labelled field in the GUI
Click 'Test and merge user proxies'.
Wait ... follow the instructions.
You may need to reselect your configuration at this point, or restart LP and select it.
Start services

Look at the example, and at the 'wayne', 'last', or 'auto' configurations to see a few of the things which may be done. In the end, it is possible to overload any of the tags used in the distributed configuration files. The appropriate technique may be seen by looking in these files. Please suggest any other tags you might want - it's easy to add them to a configuration, but it may be more difficult to make the software do the right thing with them!

Examples of the use of user configured tag use are: