Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
SNIPROXY.CONF(5)		   sniproxy		      SNIPROXY.CONF(5)

NAME
       sniproxy.conf - sniproxy	configuration file

SYNOPSIS
       /etc/sniproxy.conf

DESCRIPTION
       /etc/sniproxy.conf  is  the configuration file for sniproxy. Statements
       are separated by	either a new line or semi-colon. Lines starting	with #
       are  comments.  The configuration is broken down	into stanzas delimited
       by curly	braces.	Characters may be escaped using	\.  Configuration  di-
       rectives	 may  may be shorted as	long as	they are unambiguous e.g. user
       daemon instead of username daemon.

   USERNAME
       username	daemon

       Specify the user	sniproxy will run as. When sniproxy is launched	as su-
       per user, it will drop permissions to this user.

   PIDFILE
       pidfile /var/run/sniproxy.pid

       Specify	the  path  to the pid file, the	directory much be writeable by
       the user	sniproxy runs as.

   ERROR_LOG
       error_log {
	   syslog daemon
	   priority notice
       }

       Specify how error messages should be handled. Messages  can  be	either
       logged  to syslog using the syslog directive specifies that logs	should
       to a given syslog facility. Alternatively the filename directive	may be
       specified to log	to file, these two options are mutually	exclusive. The
       priority	directive  indicates  what  severity  of  messages  should  be
       logged. Accepted	priorities the standard	syslog priorities, in increas-
       ing verbosity: emergency,  alert,  critical,  error,  warning,  notice,
       info, and debug.

   ACCESS_LOG
       access_log {
	   filename /var/log/sniproxy/access.log
       }

       Specify	how  connections should	be logged, may be overridden in	a spe-
       cific listener. Connections are logged after both the client and	server
       have sockets have been closed. The syslog and priority directive	may be
       used here as in error_log.

   RESOLVER
       resolver	{
	   nameserver 127.0.0.1
	   mode	ipv6_first
       }

       Specify how DNS queries should be resolved, this	is  only  required  if
       using  hostnames	 as  addresses	in the configuration or	using wildcard
       backends.  If not specified the IPv4 only queries will be preformed us-
       ing the system default name servers.

       Four modes are supported:

       ipv4_only:  query  for  any  A records, use the first A record returned
       (following CNAME	records).

       ipv6_only: query	for any	AAAA records, use the first  AAAA  record  re-
       turned (following CNAME records).

       ipv4_first: query for both A and	AAAA records, wait for both queries to
       complete, use the first A record	if any,	otherwise use the  first  AAAA
       record.

       ipv6_first: query for both A and	AAAA records, wait for both queries to
       complete, use the first AAAA record if any, otherwise use the  first  A
       record.

       It  is  strongly	recommended to use a local name	server,	since a	single
       socket is reused	for all	DNS queries and	thus the UDP  port  number  is
       predictable  leaving  the  query	only protected from spoofed replies by
       the 16 bit query	ID.  Additionally since	no  internal  DNS  caching  is
       performed a local resolver can improve performance.

   LISTENER
       listener	192.0.2.10:80 {
	   protocol http
	   reuseport yes
	   table http_hosts
	   fallback 192.0.2.100:80
	   bad_requests	log
	   source 192.0.2.10

	   access_log {
	       filename	/var/log/sniproxy/http_access.log
	   }
       }

       listener	[::]:80	{
	   protocol http
	   ipv6_v6only yes
	   table http_hosts

	   fallback unix:/var/run/http_fallback_unix.sock
       }

       Define  a  listening address to accept new connections from clients on.
       Addresses may be	specified as an	IPv4 literal followed by  a  TCP  port
       number, and IPv6	literal	followed by a TCP port number, a bare TCP port
       number or a unix	socket path prefixed with 'unix:'.

       Protocol	defines	how the	client request should be parsed	to obtain  the
       requested hostname, two protocols are supported http and	tls.

       Reuseport  directive  controls  if  the	port is	opened in SO_REUSEPORT
       mode, which allows to  run  several  sniproxy  instances	 on  the  same
       ip:port	pair.  This enables us to evenly load-balance incoming connec-
       tions between these instances without the use of	any external load-bal-
       ancing  proxy.  Requires	Linux kernel 3.9+.  Setting reuseport to "yes"
       enables this functionality.

       The ipv6_v6only directive controls if listening on the IPv6 any address
       '::'  will accepting connections	to any IPv4 address as well as an IPv6
       address.	This is	useful if the user wants different configurations  for
       IPv4   and   IPv6  or  wishes  to  handle  IPv4	traffic	 with  another
       server/proxy entirely. This is only applicable to IPv6  listeners,  and
       is ignored on other listeners.

       Table  specifies	 the  name of the table	used to	lookup which server to
       forward the connection to based on the hostname extracted from the ini-
       tial  client  request.  If no table directive is	specified the default,
       unnamed,	table will be used.

       The fallback directive specifies	a server to be used if the client  re-
       quest can not be	parsed,	a server can not be found in the table for the
       hostname	specified or the hostname can not be resolved..	This should be
       an IP address and port or unix socket path.

       The  bad_requests  directive  allows logging the	contents of the	client
       request if it is	not parsable, this is useful for debugging.

       The source directive allows specifying a	specified address to  bind  to
       before  connecting to the backend server. In most cases it is better to
       omit this option	and allow the operating	system to select the  outgoing
       address	automatically.	Do  not	include	a port number in this address,
       doing so	will limit the proxy to	one simultaneous  to  each  server  at
       time.

       The access log configuration may	be overridden on each listener.

   TABLE
       table http_hosts	{
	   ^example\.com$ 192.0.2.101
	   ^example\.net$ 192.0.2.102
	   ^example\.org$ 192.0.2.103 proxy_protocol
       }

       Tables  define  how  to map each	hostname to a backend server. Each re-
       quest's hostname	is matched against entries in the table	in order,  un-
       til a match is found and	that server is used. The server	address	may be
       either IP, an IP	and port, a unix socket	path, a	hostname or '*'. If no
       port  is	 specified,  the port of the listener which connection was re-
       ceived on will be used.

       The optional proxy_protocol option will prepend a HAProxy PROXY v1 pro-
       tocol  header  to the proxied connection	allowing supporting webservers
       to obtain the source and	destination IP and port	of the original	incom-
       ing TCP connection.

SEE ALSO
       sniproxy(8)

SNIProxy manual			 22 March 2015		      SNIPROXY.CONF(5)

NAME | SYNOPSIS | DESCRIPTION | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=sniproxy.conf&sektion=5&manpath=FreeBSD+12.2-RELEASE+and+Ports>

home | help