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)

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

home | help