代理服务器

开发平台：
Visual C++

sforward.ini：源码内容
							#	Forwarding specification for Internet Junkbuster 2.0
#
# Copyright 1997-8 Junkbusters Corp.  For distribution, modification and use
# under the GNU General Public License. These files come with NO WARRANTY.
# See http://www.junkbusters.com/ht/en/gpl.html or README file for details.
# For this file to have any effect, the line beginning "forwardfile" must
# be commented in, with the name of this file following the word "forwardfile"
#
# This feature allows routing of HTTP requests via multiple proxies.
# It can be used to better protect privacy and confidentiality when
# accessing specific domains by routing requests to those domains
# to a special purpose filtering proxy such as lpwa.com
#
# It can also be used in an environment with multiple networks to route
# requests via multiple gateways allowing transparent access to multiple
# networks without having to modify browser configurations.
#
# Also specified here are special gateway protocols such as SOCKS.
# The syntax of each line is
#
# target_domain[:port][/path]	forwarding_domain[:port]	gateway_type	gateway_domain[:port]
#
# A '.' in the forwarding domain/port means that requests made to the
# target domain are not forwarded but are made directly by the proxy
# (though the proxy may still use a gateway to contact the server)
#
# Lines are checked in turn, and the last match wins.
#
# There is an implicit line equivalent to the following, which specifies that
# anything not finding a match on the list is to go out without forwarding
# or gateway protocol; like so:
#
# *	.	.	.	# implicit
# In the following common configuration, everything goes to Lucent's LPWA,
# except SSL on port 443 (which it doesn't handle)
# *		lpwa.com:8000	.	.
# :443		.		.	.
# See the FAQ for instructions on how to automate the login procedure for LPWA.
# Some users have reported difficulties related to LPWA's use of . as the
# last element of the domain, and have said that this can be fixed with this:
# lpwa.   lpwa.com:8000   .       .
# In this fictitious example, everything goes via an ISP's caching proxy,
# except requests to that ISP:
#
# *		caching.myisp.net:8000	.	.
# myisp.net	.			.	.
# For the @home network, we're told the forwarding configuration is this:
# *       proxy:8080      .       .
# Also, we're told they insist on getting cookies and Javascript, so you need
# to add home.com to the cookie file. We consider Javascript a security risk;
# see our page on cookies. Java need not be enabled.
# In this example direct connections are made to all "internal" domains,
# but everything else goes through Lucent's LPWA by way of the company's
# SOCKS gateway to the Internet.
#
# *			lpwa.com:8000	socks	argyle.my_company.com:1080
# my_company.com	.		.	.
# This is how you could set up a site that always uses SOCKS but no forwarders
#
# *			.		socks	knee.my_company.com:1080
# An advanced example for network administrators.
#
# If you have links to multiple ISPs that provide various special
#content to their subscribers, you can configure forwarding to pass
# requests to the specific host that's connected to that ISP
# so that everybody can see
# all of the content on all of the ISPs.
#
# This is tricky, but here's a sample:
# 
# host-a has a PPP connection to isp-a.com
# host-b has a PPP connection to isp-b.com
# host-a can run an Internet Junkbuster proxy with forwarding like this:
#
# /		.		.	.
# isp-b.com	host-b:8000	.	.
#
# host-b can run an Internet Junkbuster proxy with forwarding like this:
# /		.		.	.
# isp-a.com	host-a:8000	.	.
#
# Now, *anyone* on the Internet (including users on host-a and host-b)
# can set their browser's proxy to *either* host-a or host-b and
# be able to browse the content on isp-a or isp-b.

						