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 directives 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 super 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 increasing 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  specific  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 using 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 returned (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 connections between these instances without the use of any external load-
       balancing  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 initial 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  request  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  request's  hostname  is
       matched  against  entries in the table in order, until 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 received on
       will be used.

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

SEE ALSO

       sniproxy(8)